AO-A063  432  COMMAND  ANO  CONTROL  TECHNICAL  CENTER  WASHINGTON  D C F/Q  9/2 

NMCS  INFORMATION  PROCESSING  SYSTEM  360  FORMATTED  FILE  SYSTEM  (N— ETC«U) 
SEP  76  C K HILL 

UNCLASSIFIED  CCTC-CSM-OM-l5-7»-VOL-S  NL 


,f*3  1 

a8  :3  32  E 

El  f 

i ikr 

m 

<mT  ft* 

i 

1 

te-  1 1 

1 

1 ^ — 

ssss 

MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BORLAU  01  STANDARD  19fe  i A 


TnJnTraiiitfirJ 


/n? 6 /°o  tag 


A CONTROL 

TECHNICAL 

CENTER 


NMCS  INFORMATION 
PROCESSING  SYSTEM 
360  FORMATTED  FILE 


pn 

f V j 

f • T 

COMHAND  AND  CONTROL  T 


Computer ^ystea  XanuaJ; 


NHCSINF  OB  H All  CN^RO  CESS  IN  G^XSTHH 

i^JmliiBiL^iLL^isiifl-ig|g-3se-£y§i 


users  Manual* 

■»■  — 


Voluae  TTT  9 *ile  Maintenance  (?M)  , 


SUBMITTED  BY: 


IsbHgT^hill/ 

Oapluiu  USA — 

CCTC  Project  Officer 


APPROVED  BT: 


'FREDERIC  A.  GR  AF,/jR 
Captain  U.S.  Navy 
Deputy  Director 
NMCS  ADP 


Copies  of  this  docuaent  aay  be  obtained  from  the  Defense 
Docuaentation  Center,  Cameron  Station,  Alexandria,  Virginia 
22314. 


This  docuaent  has  been  approved  for  public  release  and  sale; 
its  distribution  is  unlinited. 


D D C 


JAN  18  1979 


78  12  08  028 


ACKNOWLEDGMENT 


I 


J 


I 


CONTENTS 


Section  Page 


ACKNOWLEDGMENT ii 

ABSTRACT riii 

1 INTRODUCTION 1 

2 PM  CAPABILITIES 2 

2.1  Transaction  Sources 3 

2.2  Transaction  Foreats..... 3 

2.3  Logical  Updating  and  Trans- 
action Editing 3 

2.4  Data  Conversion  and  Validation  - 

User  Subroutines 4 

2.5  Processing  of  Periodic  Sets 4 

2.6  Variable  Field  and  Variable 

Set  Maintenance 4 

2.7  Production  of  Auxiliary  Outputs 4 

2.8  Production  of  Run  History 

Information 5 

2.9  Logic  Statement  Storage... 5 

2.10  File  Update  Methods. 5 

2.11  Modes  of  Operations 6 

2.12  Transaction  Sorting 7 

2.13  Ordinary  Maintenance.... 7 

2.14  Checkpoint/Restart 8 

2.15  Segmented  Files 9 

2.16  Secondary  Indexing 9 

2.17  Auxiliary  File  Reference 10 

2.18  Logic  Statement  Size 10 

3 FM  DESCRIPTION 11 

3.1  Control  Elements 11 

3.2  FM  Functioning. 15 

4 INPUTS 20 

4.1  Card  Input.. 20 

4.1.1  PHS  Control  Card 20 

4. 1.1.1  LIMIT  Control  Card 20 

4.1.2  Segment  Control  Cards 20 

4.1.3  Logic  Statement  Library 

Update  Deck... 21 

4. 1.3.1  Library  Action  Cards 21 

4. 1.3.2  Logic  Statement  Source  Decks.. 22 


iii 


Section 


4. 1.3. 3  Logic  Statement  Library  Update 

Terminator  Card 

4.2  Transactions 

4.3  Subroutine  Library 

4.4  Data  File 

5 OUTPUTS 

5.1  Output  Data  File 

5.2  Auxiliary  Output 

5.2.1  Tape  and  Disk  Auxiliary  Output.... 

5.2.2  Punched  Card  Auxiliary  Output 

5.2.3  Printed  Auxiliary  Output 

5.3  Run  History 

5.4  File  Analysis  and  Run  Optimization 

Statistics 

6 CONTROL  CARD  FORMATS 

6.1  Pree-Fornat  Specifications 

6.1.1  FHS  Control  Card  (Pree-Fornat) . . . . 

6. 1.1.1  LIMIT  Control  Card  (Free  Format).. 

6.1.2  Segment  Control  Cards 

6.1.3  Library  Action  Card  (Free-Format) . 

6.1.4  Transaction  Descriptor  (TD)  Cards 

(Free* Format)  

6.1.5  Language  Identifier  Card 

6.1.6  Logic  Statement  END  Card 

6.1.7  Logic  Statement  Library  Update 

Terminator  Card 

6.1.8  Report  Identifier  Card............ 

6.2  Ordinary  Maintenance  (OH) 
Transaction  Descriptor  (TD)  Cards. 

6.2.1  Keyword:  FIELD 

6.2.2  Keyword:  CONTROL 

6.2.3  Keyword:  PICTURE 

6.2.4  Keyword:  VALUE 

6.2.5  Keyword:  RANGE 

6.2.6  Keyword:  VERIFY 

6.2.7  Keyword:  CONVERT 

6.2.8  Keyword:  GENERATE 

6.2.9  Keyword:  EPROR 

6.3  Fixed'Format  Specifications....... 

6.3.1  FHS  Control  Card 

6.3.2  Library  Action  Cards 

6.3.3  Transaction  Descriptor  (TD) 

Ca 

6.3.4  Language  Identifier  Card 


POOL  LANGUAGE 


Section 


Page 


7.1  Card  Fora  at 59 

7.1.1  Syabols 59 

7.1.2  Operators 59 

7.1.3  Operands 59 

7.1.4  Comments 59 

7.2  Operand  Coding 60 

7.3  POOL  Instructions. 62 

7.3.1  Alphabetical  Listing 62 

< . 7.3.2  Valid  Operands  Chart 68 

7.3.3  Instruction  Groups 73 

7.4  POOL  Instructions 80 

7.4.1  Environment  Handling  Instructions...  80 

7.4.2  Data  Handling  Instructions. 83 

7.4.3  Control  Instructions 92 

7.4.4  Display  Instructions 100 

I 7.4.5  Ordinary  Maintenance  Validity  Test 

Instruct  ions. 102 

7.4.6  Transaction  Error  Log  Instruction 

(SODA  and  on) 103 

7.5  Logic  Statement  Examples 104  > 

7.5.1  RMS  Control  Card 104 

7. 5. 1.1  LIMIT  Control  Card 104 

7.5.2  Library  Action  Card  to  Add  a Report..  105 

7.5.3  Logic  Statement  Setup 105 

7.5.4  Use  of  Data  Conversion  Subroutines...  109 

7.5.5  Periodic  Set  Processing 112 

7.5.6  Test  for  Nueeric  Data... 116 

7.5.7  Production  of  Summary  Information....  119 

7.5.8  Variable  Pield  and  Set  Processing . . • . 122 

7.6  Summary  of  POOL  Instructions.... 126 


8 ORDINARY  MAINTENANCE  (OM)  EXAMPLES...  129 

8.1  Use  of  Ordinary  Maintenance  TD  Cards.  129 

8.2  Use  of  Ordinary  Maintenance  TD  Cards 


and  POOL  Instructions 129 

9 NEH  PILE  MAINTENANCE  LANGUAGE  (NFL).  131 

9.1  NPL  Statement  Composition. 131 

9.1.1  Statement  Identifiers... 132 

9.1.2  Keywords.... 133 

9.1.3  Noise  Words. ...........  135 

9.1.4  Statement  Labels..... 135 

9.1.5  Operands 136 

9. 1.5.1  Control  Location  Operands...........  136 

9.1. 5. 2 Subroutine/Table  Name  Operands......  136 

9.1. 5. 3 Literal  Value  operands 137 

9. 1.5. 4 Data  Location  Operands 137 

9.1. 5.4.1  Pile  Data  Operands 138 


v 


Section 


Page 


9. 1.5. 4. 2 Transaction  Data  Operands 136 

9.1. 5.4.3  Indirect  Data  Operands 139 

9. 1.5. 4. 4 Defined  Constant  and  Area  Operands.  139 

9.2  Special  Requirements  and 

Considerations 139 

9.2.1  Data  Node  Compatibility 140 

9.2.2  Data  Length  Coepat ibility 141 

9.2.3  Special  Statement  Sequence 

Reguirenents...... 141 

9. 2. 3.1  Condition/Action  Statement  Sequence.  142 

9. 2. 3.2  Procedure  Definitions 143 

9. 2. 3.3  Define  Sequence  Requirements 144 

9.2.4  Subset  Positioning 144 

9.3  NFL  Statement  Description.. 145 

9.3.1  Conditional  Statements 145 

9.3. 1.1  Relational  Condition 146 

9.3. 1.2  Table  Validation 148 

9. 3. 1.3  Picture  Hask. 146 

9. 3. 1.4  Switch  Test 149 

9.3. 1.5  Bit  Hask  Test..... 150 

9.3. 1.6  New  Record  Test.. 151 

9.3. 1.7  Job  Complete  Test 151 

9.3. 1.8  Overflow  Test....... 152 

9.3.2  Action  Statements 152 

9. 3.2.1  Data  Movement.. 152 

9. 3. 2. 1.1  The  HOVE  Statement 152 

9. 3. 2. 1.2  The  ATTACH  Statement 154 

9.3. 2.2  The  COMPUTE  Statement 154 

9. 3.2.3  Subset  Positioning  Statements 155 

9. 3. 2. 3.1  The  LOCATE  Statement 156 

9. 3. 2. 3.2  The  STEP  Statement 156 

9.3.  2.3.3  The  POSITION  Statement 156 

9. 3. 2. 4 Auxiliary  Output  Statements 159 

9. 3.2.4. 1 The  PRINT  Statement 159 

9. 3. 2.4.2  The  PUNCH  Statement 160 

9. 3. 2. 4. 3 The  HRITE  Statement 160 

9.  3. 2. 4. 4 The  DISPLAY  Statement 160 

9.3. 2. 5 The  BUILD  Statement 161 

9. 3. 2.6  The  DELETE  Statement 162 

9. 3. 2. 7 The  DEFINE  Statement 163 

9. 3. 2. 7.1  Defining  a Constant........... 163 

9. 3. 2.7.2  Defining  an  Interlogic  Statement 

Work  Area.. 164 

9. 3. 2. 7. 3 Defining  an  Intralogic  Statement 

Work  Area 165 

9. 3. 2.7.4  Defining  and  Initializing  an  Area...  165 

9. 3. 2. 8 The  TURN  Statement 166 


vi 


i 


Section 


9.3. 2.9 

9. 3.2.9 
9.3. 2.9 
9.3.3 

9.3. 3.1 

9.3. 3.2 

9. 3. 3. 3 

9. 3. 3.4 

9.3. 3.5 

9. 3. 3. 6 
9.4 
9.4.  1 

9.4.2 

9.4.3 

9.4.4 

9.4.5 

9.4.6 

9.4.7 

9.4.8 

9.5 


APPENDIX 


A 


Page 


Execution  Sequence  changing 

Statements 167 

1 The  GO  Statement 167 

2 The  RETURN  Statement 168 

Control  Point  Identifiers 168 

The  NOTE  Statement 168 

The  PROCEDURE  Statement 169 

The  END  Statement 169 

The  ELSE  Statement 170 

The  CONTINUE  Statement 170 

The  Language  Identifier  Statement...  171 

NFL  Logic  Statement  Examples 172 

FNS  Control  Card 172 

Library  Action  Card  to  Add  a Report.  172 

Logic  Statement  Setup..... 173 

Use  of  Data  Conversion..............  177 

Periodic  Set  Processing 179 

Test  for  Numeric  Data 182 

Production  of  Summary  Information...  184 
Variable  Field  and  Variable  Set 

Processing 186 

Summary  of  NFL  Condition  and  Action 
Statement  Syntax 188 

Utilizing  a NIPS  File  as  PH  Transaction 
Input 195 


i 


DISTRIBUTION 197 

DD  Form  1473 201 


vii 


ABSTRACT 


This  volume  defines  the  File  Maintenance  (PH)  component 
of  MIPS  360  FFS.  It  describes  the  functioning  of  the 
component,  its  capabilities,  limitations,  expected  output 
results,  and  specifications  for  preparing  run  decks  and 
control  cards  which  will  serve  as  reference  for  the 
knowledgeable  user.^ 

This  document  supersedes  fgM  mm 
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Section  1 


INTFODUCTION 


The  File  Maintenance  (FM)  voluie  of  the  Users  Manual  is 
divided  into  nine  sections. 

Section  1 presents  a brief  introduction  to  the  annual. 

Section  2 describes  the  capabilities  of  the  FM  component 
in  generating  and  updating  data  files. 

Section  3 gives  detailed  information  on  FM  transactions 
under  the  control  of  FHS  control  card  and  logic  statements. 

Section  4 describes  input  to  the  FM  component. 

Section  5 discusses  the  output  from  the  FM  component. 

In  summary,  sections  2 through  5 give  the  user  an 
insight  to  the  general  functioning  of  the  component,  its 
capabilities,  and  limitations.  A thorough  understanding  of 
these  sections  is  necessary  before  attempting  to  use  the 
system. 


The  remaining  four  sections  describe  the  specifications 
for  preparing  run  decks  and  control  cards  for  the  FM 
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Section  2 


FM  CAPABILITIES 


The  FM  component  provides  the  NIPS  360  FFS  user  with  a 
tool  for  generating  and  maintaining  data  files.  For  maximum 
efficiency,  updating  is  performed  on  indexed  sequential 
access  method  (ISAM)  or  virtual  storage  access  method  (VSAM) 
files  residing  on  Direct  Access  Storage  devices  (DASD) . 
This  permits  random  access  of  only  those  records  that  are  to 
be  processed  on  any  given  run;  only  records  that  require 
processing  are  retrieved  from  the  file.  Record  subsets, 
whose  data  content  is  modified,  are  written  back  into  the 
file.  The  file  is  updated  in  place;  only  those  records 
requiring  modification  are  rewritten. 

The  component  is  capable  of  generating  and  adding  new 
records  and  subsets  to  the  file  or  deleting  records  and 
subsets.  Another  feature  of  the  system  is  its  ability  to 
increase  or  decrease  the  size  of  existing  records  and 
subsets  through  the  addition  or  deletion  of  variable  data. 
All  of  these  functions  can  be  accomplished  in  one  update 
cycle. 

The  component  also  has  the  capability  to  generate  and 
maintain  segments  of  a sequentially  organized  file.  This 
capability  will  allow  large  chronological  files  to  be 
segmented  as  specified  by  the  user  to  expedite  processing 
when  the  primary  updating  to  be  performed  is  addir.g  new 
records  with  a higher  key  than  those  already  present  in  the 
data  file.  Each  segment,  when  generated,  will  be  a separate 
data  file  that  can  be  processed  singly  or  concatenated  with 
other  segments  as  one  data  file. 

During  FM,  the  user  has  the  option  of  specifying  the 
file  block  size  when  generating  either  an  indexed  sequential 
or  physical  sequential  file,  or  when  updating  a physical 
sequential  file.  If  a block  size  is  not  specified,  the 
output  file  block  size  will  be  the  same  as  the  input  FFT  or 
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the  input  file.  For  details  of  file  block  size 
specification,  see  Volume  VIII,  Job  Preparation  Manual. 
Block  size  modification  is  not  possible  with  VSAM  DATA  files 
during  FM 

The  FN  component  features  are  discussed  in  the  following 
paragraphs.  Another  option  available  to  the  user  is  to 
limit  the  records  read  from  the  data  file  to  be  processed. 
This  can  be  done  through  the  use  of  a LIMIT  statement. 


2.1  Transaction  Sources 

The  FM  component  will  accept  fixed  or  variable  length, 
blocked  or  unblocked,  or  undefined  transaction  records  from 
tape,  disk,  or  card  files.  The  transaction  files  way  be 
organized  seguent iaily,  or  in  indexed  sequential  form  on 
disk.  The  latter  capability  permits  the  FFS  data  file  to  be 
used  as  transaction  input  to  update  another  EPS  data  file. 
Transaction  files  nay  also  be  VSAM  FFS  data  files. 

2.2  Transaction  Formats 

On  any  given  FN  run,  file  updating  can  be  performed  with 
a variety  of  transaction  record  formats,  from  any  number  of 
different  reporting  sources.  This  capability  allows  new 
information  management  systems  to  be  developed  without 
seriously  impacting  existing  information  management  systems 
and  existing  reporting  systems. 

2.3  Logical  Updating  and  Transaction  Editing 

The  PH  component  automatically  performs  all  of  the  I/O 
functions,  record  positioning,  and  new  record  generation 
required  for  a file  update  run;  however,  the  user  supplies 
the  actual  record  update  logic  to  be  used  by  writing  file 
maintenance  logic  statements.  The  user  writes  one  logic 
statement  for  each  different  transaction  record  format  that 
is  used  to  update  his  file.  The  logic  statements  are 
written  in  the  File  Haintenance  languages  (POOL  or  NFL) . 
These  languages  provide  a full  complement  of  comparative  and 
arithmetic  functions,  so  that  the  user  can  perform  all  of 
his  transaction  data  editing  validation  in  conjunction  with 
his  file  update.  In  most  applications,  no  preprocessing  or 
preediting  of  transaction  data  should  be  required. 
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2.4  Data  Conversion  and  Validation  - User  Subroutines 

In  addition  to  the  comparative  and  arithmetic  commands, 
the  FN  languages  also  provide  the  user  with  commands  that 
allow  him  to  perform  on-line  validation  and  conversion  of 
transaction  data  with  subroutines  that  nay  be  written  in  any 
of  the  S/360  languages  (COBOL,  FORTRAN,  PL1)  or  in  S/360 
Assembler  language.  These  subroutines  can  be  prestored  on 
a load  library,  using  the  NIPS  360  FFS  utility,  0TS0BLDR, 
and  can  be  accessed  by  the  FN  component  as  they  are 
reguired.  A NIPS  360  FFS  utility,  TABGEN , has  been  provided 
to  generate  tables  that  perform  data  conversion  and 
validation  using  the  table  search  technique  (see  section  2, 

Volume  VII,  Utility  Support.) 

2.5  Processing  of  Periodic  Sets 

The  FM  languages  contain  a series  of  commands  that  allow 
the  user  to  scan  the  periodic  sets,  so  that  he  nay  ^ 

selectively  update  subsets  based  on  their  existing  data 
contents.  These  commands  also  allow  the  user  to  control  the 
physical  sequence  of  subsets  in  a set  when  new  subsets  are 
being  added. 

2.6  Variable  Field  and  Variable  Set  Maintenance 

The  FM  languages  provide  a set  of  commands  for  adding, 
deleting,  or  replacing  information  in  the  variable  fields 
and  the  variable  sets. 

2.7  Production  of  Auxiliary  Outputs 

The  FM  languages  provide  a set  of  commands  for  producing 
auxiliary  outputs  on  printer,  punch,  direct  access  device  or 
tape  in  conjunction  with  a file  update.  These  outputs  can 
be  used  to  provide  an  audit  trail  of  the  updates  or  to 
produce  transaction  files  that  might  be  used  to  update  other 
files  in  a file  system.  Two  separate  printed  reports,  two 
separate  punched  outputs,  and  up  to  five  auxiliary  files  nay 
be  produced.  The  user  has  access  to  a 999-byte  work  area 
for  formatting  auxiliary  output  records.  Each  record  is 
limited  to  a maximum  of  994  bytes  because  NIPS  adds  six 
overhead  bytes  to  the  data  and  the  DCB  LRKCL  is  1000. 

Violation  of  this  limit  will  cause  a System  001  ABEND  (I/O 
ERROR,  RECORD  TOO  LONG).  Information  can  be  selected  for 

| 
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output  fron  either  the  transaction  records  or  the  data 
records.  The  PM  languages  also  provide  the  capability  for 
■aintaining  suaeary  counts  and  totals  which  can  be  output  to 
tape,  print,  or  punch.  The  user  has  access  to  20  full-word 
binary  work  areas  for  developing  sunnary  infornation  in 
conjunction  with  a file  update  run. 

2.8  Production  of  Bun  History  Infornation 

The  PH  conponent  autonaticall y produces  a printed  run 
history  to  indicate  error  conditions  that  were  encountered 
during  file  updating.  The  run  history  is  printed  separately 
fron  the  printed  auxiliary  output. 

2.9  Logic  Statenent  Storage 

The  FM  conponent  naintains  a library  of  the  user-written 
logic  statenents  (in  coapiled  fora)  to  update  a file.  The 
Logic  Statenent  Library  is  naintained  with  the  data  file  and 
consists  of  a series  of  records  with  special  keys.  This 
capability  allows  the  user  to  avoid  reconpilation  of  the 
statenents  each  tine  his  file  is  to  be  updated,  thereby 
reducing  execution  tine.  The  conponent  autoaatically 
retrieves  the  logic  statenents  that  are  required  for  the 
transaction  record  fornats  encountered  during  an  update 
cycle.  The  user  can  add/delete  statenents  on  the  Logic 
Statenent  Library  by  using  a set  of  control  cards,  called 
library  action  cards  (see  section  4.1.2). 

2.10  Pile  Update  Methods 

The  PH  user  can  cause  the  PH  conponent  to  enploy  any 
conbination  of  the  following  file  update  nethods  in  a given 
file  naintenance  run. 

a.  Sanaa  Updating  - Using  this  nethod,  every  record  of 
the  data  file  is  aade  available  for  logical 
updating.  This  nethod  nay  be  used  to  nake 
corrections  to  sone  data  field  in  the  file  or  to 
produce  suaaary  infornation.  If  at  all  possible, 
this  nethod  should  not  be  used  as  a part  of  nornal 
production  runs  since  it  greatly  reduces  the 
efficiency  of  the  conponent.  However,  when  it  is 
deened  necessary,  the  RANGE  statenent  should  be 
conpiled  and  stored  on  the  library  in  accordance 
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with  the  paragraph  "Logic  Statements"  under  section 
3.1,  Control  Elements. 

b.  Exception  Updating  - Using  this  aethod,  each 
transaction  record  is  latched  against  a particular 
data  record,  which  is  aade  available  for  logical 
updating.  Rhen  no  natch  is  found,  a new  data 
record  is  generated,  and  a 'new  record*  indicator 
is  set  which  the  user  can  test  by  using  one  of  the 
PM  language  coaiands  in  his  logic  statement. 
Exception  updating  is  the  noraal  update  aethod. 

c.  Exception-Range  Updating  - Using  this  method,  each 
record  that  has  been  subjected  to  exception 
updating  is  aade  available  for  further  processing 
by  one  or  lore  exception-range  logic  statements. 
This  aethod  can  be  used  for  collecting  summary 
information  or  fcr  producing  audit  information  on 
all  records  affected  by  an  update  cycle. 

d.  Direct  Subset  Updating  - Using  this  aethod,  a 
transaction  record  is  matched  against  a particular 
data  record  subset  and  the  record's  fixed  set,  and 
the  particular  subset  is  aade  available  for 
processing.  Rhen  no  subset  match  is  found,  a new 
subset  is  generated,  unless  the  record  does  not 
exist.  In  the  latter  case,  the  transaction  is 
logged  as  an  error  on  the  run  history. 

2.11  Modes  of  Operations 

Pour  PH  component  modes  of  operation  may  be  specified  by 
the  user.  (Any  given  PH  run  nay  be  executed  in  only  one 
mode  of  operation.) 

Compile  Logic  Statement  node  - This  mode  allows  the  user 
to  get  compilations  of  his  logic  statement  for  the  purpose 
of  debugging.  The  component  produces  a symbolic  listing 
with  all  errors  flagged,  along  with  a summary  of  the  errors 
and  their  causes.  Processing  is  completed  when  the  last 
statement  is  compiled.  No  logic  statements  can  be  added  to 
the  File  Library  portion  of  the  data  file  in  this  mode,  but 
any  other  actions  can  be  performed  on  the  Logic  Statement 
Library.  If  the  data  file  is  sequentially  organized,  no 
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library  actions  will  be  performed  on  the  Logic  Statement 
Library. 

Logic  Statement  Library  Update  Mode  - When  this  node  of 
operation  is  specified,  PH  updates  the  Logic  Stateaent 
Library  as  specified  by  the  library  action  cards.  Logic 
stateaents  aay  also  be  coapiled  in  this  aode  and  placed  on 
the  Logic  Stateaent  Library.  If  the  data  file  is 
sequentially  organized,  logic  stateaents  cannot  be  added  to 
the  logic  stateaent  portion  of  the  'data  file  during  this 
node. 


Data  File  Generation  Mode  - The  user  specifies  this  node 
of  operation  when  he  wishes  to  generate  a new  file.  The 
coaponent  will  also  coapile  logic  stateaents  and  perfora 
Logic  Stateaent  Library  aaintenance  if  specified.  At  this 
tiae,  the  user  aay  specify  the  file  block  size  using  the 
BSZNEHF  syabolic  paraaeter  of  the  XFH  procedure.  If  a block 
size  is  not  specified,  it  will  be  set  at  the  size  of  the 
input  PPT. 

Data  File  Update  Mode  - This  aode  of  operation  is 
specified  when  the  user  wishes  to  update  a data  file.  Logic 
stateaent  coapilation  and  library  aaintenance  nay  also  be 
perforaed  by  the  coaponent  when  executed  ..  in  this  node  of 
operation.  If  the  file  is  sequentially  organized,  the  user 
aay  specify  a new  file  block  size  using  the  BSZNSWP  syabolic 
paraaeter  in  the  XPN  procedure.  If  a new  block  s.ize  is  not 
specified,  it  will  be  set  at  the  size  of  the  input  file. 


2.12  Transaction  Sorting 

The  FM  coaponent  autoaatically  sorts  all  transaction 
records  into  sequence  on  the  transaction  control  fields 
prior  to  updating  a file.  The  sort  will  be  *ccoaplished  on 
tape  or  disk.  When  the  transaction  voluae  is  such  that  the 
disk  sort  capacity  is  exceeded,  a tape  sort  will  be 
executed.  If  the  transactions  are  already  in  order,  the 
sort  is  autoaatically  bypassed. 

2.13  Ordinary  Maintenance 

Through  the  use  of  the  Ordinary  Maintenance  (ON) 
Transaction  Descriptor  (TD)  cards  (see  section  6.2),  the 
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user  nay  specify  automatic  validation  of  transaction  data, 
and  autoaatic  (unconditional)  updating  of  file  fields.  The 
types  of  data  validation  that  aay  be  performed  are  value, 
range,  picture,  and  verification  against  a table  or 
subroutine.  Data  conversion  through  use  of  table  or 
subroutine  is  also  permitted.  Error  options  are  provided  to 
permit  or  suppress  autoaatic  logging  of  erroneous  data,  to 
automatically  delete  records  of  subsets  generated  by  the 
erroneous  transaction  data,  or  to  automatically  clear  the 
data  field  that  corresponds  to  the  erroneous  transaction 
field. 

The  Ordinary  Maintenance  capability  permits  the  user  to 
write  logic  statements  that  contain  only  Ordinary 
Maintenance  Transaction  Descriptor  cards,  or  to  write 
statements  that  contain  both  Ordinary  Maintenance  cards  and 
PM  statements.  Instructions  are  provided  in  the  PH  language 
to  interrogate  the  results  of  the  Ordinary  Maintenance 
validation  (see  section  7.4.5).  This  allows  the  user  to 
perform  part  of  the  validation  function  using  the  Ordinary 
Maintenance  language,  and  to  perform  the  more  complex  edits 
and  data  manipulation  in  the  PM  language  in  one  logic 
statement.  In  a nixed  logic  statement,  the  Ordinary 
Maintenance  functions  are  executed  prior  to  the  PM  language 
functions. 


2.14  Checkpoint/Restart 

f 

During  the  generate/update  phases  of  SAN  processing,  the 
user  aay  invoke  the  OS/360  checkpoint/restart  capability  to 
record  timed  or  end-of-volume  checkpoints.  End-of -volume 
checkpoints  will  be  taken  on  the  SAM  data  file  input  for  an 
PH  SAM  update  and  on  the  user's  SAM  transaction  input,  if 
there  is  one,  for  a generate  or  an  update.  The 
checkpoint/restart  capability  should  be  used  only  during 
long-running  jobs  using  the  execute  only  procedures.  (Note 
that  OS/360  step  restart  is  program-independent  and  is  not 
the  topic  of  this  discussion.  A detailed  description  of  the 
OS/360  checkpoint/restart  capability,  which  is  utilized  in 
NIPS,  is  available  to  the  interested  user  in  IBM  Systems 
Reference  Library,  Number  C28-6708.)  A detailed  description 
of  how  to  use  checkpoint/restart  in  NIPS  is  included  in  the 
Job  Preparation  Manual,  Volume  VIII. 
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2. 15  Segaented  Piles 

The  segmented  file  capability  is  priaarily  for  users 
with  large  chronological  files  where  the  updating  process 
consists  of  adding  new  records  with  higher  Record  IDs  than 
those  already  present  on  the  data  file.  By  segnenting  the 
data  file  to  cover  a specified  range  of  Pecord  IDs,  the  user 
can  generate  a segnent  using  the  FFT  and  logic  stateaents 
froa  the  previous  segaent.  The  coaponent  will  build  segnent 
control  records  containing  the  boundary  of  a segaent  and  the 
volune  serial  nuaber  of  the  segaent  such  that  the  aost 
recent  segaent  will  contain  segaent  control  records 
identifying  all  previous  segaents. 

The  capability  exists  to  allow  the  user  to  aaintain  an 
ISAM  or  VSAH  data  file  containing  the  FFT,  logic  statements 
and  segaent  records  for  his  segnented  data  file.  This  file 
would  contain  the  aost  recent  version  of  all  logic 
stateaents  and  segaent  records  identifying  all  segaents  used 
with  the  capability.  In  general  the  ISAM  or  VSAH  data  set 
aay  be  used  in  a generate  segaent  run  in  the  saae  Banner  in 
which  a SAH  data  set  is  generated  froa  a DISK  FFT.  In  an 
update  run,  the  ISAM  or  VSAH  data  set  aust  be  defined  on  the 
ISAMHORK  DD  card. 

Exaaples  are  provided  in  Volune  VIII,  Job  Preparation 
Manual,  to  illustrate  nethods  for  generating  and  aaintaining 
segaents  of  a data  file. 


2.16  Secondary  Indexing 

Secondary  Indexing,  if  active  for  the  file  being 
updated,  operates  within  FH  in  an  entirely  automatic  Banner, 
without  user  intervention.  The  aaintenance  function 
consists  essentially  of  analyzing  the  updates  of  the  data 
file  and  aodifying  the  Index  Data  Set  to  confora  to  the 
changed  data  file.  The  analysis  includes  all  pertinent 
keyword  functions:  recovery  of  words  froa  keyword  fields 
being  updated  and  the  application  of  stop  word  tables  and 
dictionaries  (if  any)  to  the  recovered  words. 
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2.17  Auxiliary  Pile  Reference 

with  the  POOL  language  operator,  APR,  PH  features  a 
capability  to  retrieve  data  froa  the  fixed  sets  of  other 
NIPS  ISAM  or  VSAH  files  during  the  update  process  of  PM 
enabling  the  user  to  expand  transaction  editing  without 
additional  tables  or  multiple  passes  of  transactions  against 
related  files.  This  capability  allows  the  user  to  retrieve 
data  froa  an  unliaited  nuaber  of  NIPS  ISAM  or  VSAH  files 
other  than  the  priaary  data  file  in  a single  logic 
stateaent.  The  user  aust  supply  a DD  card  for  each 
auxiliary  file  referenced.  OPENS  and  CLOSES  of  the  files 
are  autoaatic  with  a aaxiaua  of  five  files  OPENed 
simultaneously. 


2.18  Logic  Stateaent  Size 

Neither  POOL,  OH  nor  NPL  compilers  restrict  the  size  of  J 

a user  written  logic  stateaent  due  to  base  register 
liaitations.  Certain  restrictions  on  logic  stateaent  size 
do  exist,  however,  and  are  listed  below. 

a.  The  user  nay  define  no  aore  than  4096  characters  of 
constants  or  literals  in  one  logic  stateaent, 
except  in  an  OH/POOL  logic  stateaent,  where  the  OM 
section  and  POOL  section  aay  each  contain  4096 
bytes  of  constants  or  literal  values. 

b.  In  POOL  and  NPL,  no  aore  than  4096  bytes  of 
executable  code  can  be  generated  between  user- 
defined  labels.  As  a practical  example,  less  than 
4096  bytes  of  code  are  generated  by  100  contiguous 
HAL  instructions  or  15  contiguous  MVP  instructions. 

If  a seguence  of  code  in  POOL  or  NPL  does  generate 
over  4096  bytes  of  code  without  labels  present,  an 
asseably  addressability  error  will  occur,  in  which 
case  the  user  need  only  label  his  source 
instructions  at  appropriate  intervals  and  recoapile 
the  logic  statement. 

c.  For  any  one  logic  stateaent,  a aaxiaua  of  255 
records  can  be  written  to  the  logic  statement 
library,  thus  limiting  a logic  stateaent  to  a 
aaxiaua  size  of  approximately  80,000  bytes. 
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Section  3 


FH  DESCRIPTION 


In  addition  to  the  PH  logic  statements,  the  PH  coaponent 
functions  under  the  control  of  intonation  that  exists  in 
the  user-supplied  control  cards  and  in  the  transaction  and 
data  file  records.  The  function  and  interaction  of  these 
elements  is  discussed  in  the  following  paragraphs. 

3.1  Control  Eleaents 

The  PH  coaponent  operates  under  the  control  of  the 
following  eleaents  of  information;  PHS  control  card,  LIMIT 
control  card  transactions,  and  logic  stateaents. 


L 


PHS  Control  Card  - The  user  must  provide  an  PHS 
control  card  (see  subsection  6.1.1  and  6.3.1)  for 
each  PH  run.  It  specifies  the  functions  that  the 
PH  is  to  perform. 

o LIMIT  Control  Card  - The  user  may  optionally 
provide  a LIMIT  card  (see  subsection  4. 1.1.1 
and  6. 1.1.1).  It  specifies  the  range  of 
records  to  be  processed. 


b.  Transactions  - Transaction  records  are  source-data 
records  containing  information  used  to  update  the 
data  records.  The  transaction  records  nay  also 
contain  two  eleaents  of  control  information.  They 
are  the  transaction  ID  fields  and  the  transaction 
control  fields. 


o 


Iraasaction_tp  fj.ej.fls  - since  sore  than  one 
type  of  transaction  record  can  be  used  to 
update  a given  data  file,  each  transaction 
record  must  contain  information  that  uniguely 
identifies  its  foraat.  The  fields  that 
contain  this  identifying  information  are  the 
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transaction  ID  fields.  Each  transaction  aay 
contain  up  to  three  ID  fields.  The  aggregate 
length  of  the  transaction  ID  fields  aay  not 
exceed  six  characters. 


transaction  record  is  to  be  applied  to  a 
particular  data  file  record  or  a record 
subset,  that  transaction  aust  contain  control 
fields.  The  aost  significant  inforaation 
contained  in  these  fields  is  identical  to  the 
inforaation  contained  in  the  control  fields  of 
the  data  record  to  which  the  transaction 
applies.  The  least  significant  inforaation  in 
these  fields  aay  be  used  to  control  the 
sequence  in  which  different  transactions  are 
processed  against  a given  data  record  and  aust 
not  exceed  10  characters.  The  user  specifies 
the  location  of  transaction  control  fields  J 

through  the  use  of  transaction  description 
cards,  which  are  a part  of  the  logic 
stateaents.  A transaction  record  aay  contain 
up  to  255  characters  of  control  inforaation 
which  aay  include  up  to  10  characters  of  user 
control  inforaation  in  as  aany  as  60 
noncontiguous  fields. 

o IiaH£dCii2a__R££2£t._Id,entili£ation  - Each 

transaction  that  is  used  to  update  a file  I 

contains  a transaction  ID.  The  location  of 

the  transaction  ID  fields  for  all  of  the 

different  transactions  within  a given  report 

aust  be  the  saae.  To  identify  the  location  of 

the  transaction  ID  fields,  the  user  aust 

assign  a report  naae  to  each  set  of 

transactions  with  ID  fields  in  unique 

locations.  The  report  naae  aust  confora  to 

the  systea  naae  rules  specified  in  Voluae  I, 

Introduction  to  Pile  Concepts.  Before  PM  will 
coapile  the  logic  stateaents  that  are  used  in 


processing 
transaction 
be  placed 
through  the 

a given  set  of  transactions,  the 
report  identification  record  aust 
on  the  Logic  Stateaent  Library 
use  of  a library  action  card. 

12 
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Transactions  that  are  being  processed  during 
an  PH  run  Bust  be  identified  by  a report  naae 
before  they  can  be  processed  through  the  use 
of  the  PMS  control  card  and  report 

identification  card.  Transactions  froa 
several  different  reports  say  be  used  to 
update  a file  on  a given  run.  Report 
identification  cards/records  Bust  be  inserted 
in  the  input  streaa  between  groups  of 
transactions  froa  different  reports. 

c.  Louie  Stateaents  - in  addition  to  specifying  the 
processing  logic,  the  analyst  aust  also  include 
certain  control  infornation  in  his  logic 

stateaents.  This  inforaation  is  used  to  specify 
the  type  of  logic  stateaent  he  is  constructing  and 
to  identify  the  logic  stateaent  so  that  it  aay  be 
retrieved  froa  the  library. 

There  are  six  types  of  logic  stateaents: 

° MfiG£_Stateisilts_witiio)it  JTL&Dsaction  _£&££  " 

RANGE  stateaents  without  transaction  data  are 
used  to  perfora  logical  processing  on  every 
record  in  the  data  file.  The  analyst 

specifies  this  type  of  stateaent  by  oaitting 
transaction  inforaation  when  he  aakes  the 
library  action  cards  for  his  logic  stateaent. 
This  type  of  stateaent  cannot  be  stored  and 
aust  be  recoapiled  for  each  FH  execution.  It 
should  be  noted  that  this  type  of  stateaent 
can  easily  be  converted  to  a range  with 
transaction  data  in  accordance  with  the 
paragraph  below  to  perait  storing  on  the 
library.  A single  transaction  description 
card  containing  a noncontrol  field  (i.e. , 

JLSNAH, 1,1)  with  the  appropriate  ASP  card 
would  fulfill  the  reguireaents  for  storage  of 
a logic  stateaent.  A single  transaction  with 
the  applicable  transaction  control  ID  coluans 
filled  in  would  subseguently  invoke  the  logic 
stateaent  at  generate/update  tine  (e.g.,  an  A 
in  the  first  position  of  a transaction) . 
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o RANGE  Statements  w^th  ?yai>sact^Qn  Data  - RANGE 
stateaents  with  transaction  data  are  used  to 
perfora  logical  processing  on  every  record  in 
the  data  file  and  to  update  the  record.  The 
analyst  specifies  this  type  of  stateaent  by 
not  specifying  transaction  control  fields  when 
he  makes  up  transaction  description  cards  for 
his  logic  stateaent.  This  type  of  stateaent 
aay  be  stored  on  the  Logic  Statement  Library 
and  need  not  be  recoapiled  for  later  use. 

RANGE  stateaents  apply  to  the  entire  data  file 
while  EXCEPTION  stateaents  apply  to  one 

specific  record.  These  types  of  updating 
operations  aay  be  coabined.  J 

o EXCEPTION  Stateaents  - EXCEPTION  stateaents 
always  require  transaction  data  and  are  used 
to  process  a particular  record  of  a data  file. 

The  transaction  control  fields  indicate  which 
record  is  to  be  processed.  The  analyst 
specifies  this  type  of  stateaent  by  specifying 
the  location  of  the  transaction  control  fields 
in  the  transaction  description  cards. 

EXCEPTION  stateaents  aay  be  stored  on  the 

Logic  Statement  Library  and  need  not  be 
recoapiled  for  later  use. 

stateaents  process  a particular  subset  record 

of  a data  file.  The  analyst  specifies  this 
type  of  stateaent  by  specifying  a subset  field 
as  a ainor  control  field  in  his  transaction 
description  cards.  The  subset  ID  aust  be 
unigue  within  its  set.  The  transaction 
control  fields,  major  and  ainor,  indicate  the 
subset  to  be  processed.  This  type  of 
stateaent  aay  be  stored  and  need  not  be 

recoapiled  for  later  use. 

o - exception  range 

stateaents  nay  be  with  or  without  transaction 
data.  The  statements  are  used  on  a per-record 
basis  to  process  all  data  records  in  the  file 
that  have  been  updated  via  EXCEPTION 
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stateaents  during  a given  run.  The  analyst 
specifies  this  type  of  stateaent  by  using  the 
POOL  XNP  instruction  written  in  the  POOL 

language  logic  stateaent,  or  by  punching  XNP 
as  the  sixth  paraaeter  in  a free  foraat  Add 
Stateaent  card  (subsection  6.1.2)  when  using 
Ordinary  Maintenance  or  the  NFL.  These 
stateaents  can  be  stored  on  the  Logic 

Stateaent  Library  when  they  are  associated 
with  transaction  data. 

o Logic  Stateaent  Identification  - All  logic 
stateaents  except  RANGE  and  EXCEPTION  RANGE 
stateaents  without  transaction  data,  aust  be 
uniquely  identified  within  a data  file. 

Stateaent  identification  is  accoaplished 

through  the  use  of  the  library  action  card 
that  aust  precede  each  logic  stateaent 

compiled.  The  report  naae  and  the  stateaent 
aust  be  specified. 

The  report  naae  identifies  the  report  type  and  provides 
the  location  of  the  transaction  ID  field  for  a set  of 
transaction  records;  this  is  the  higher  level  of 
identification. 

The  stateaent  naae  aust  be  identical  to  the  transaction 
ID  on  the  transactions  used  with  the  logic  stateaent.  This 
is  the  lower  level  of  identification  and  aust  be  unique 
within  a given  report. 

3.2  PH  Punctioning 

The  PH  coaponent  is  divided  into  the  following 
functional  sections: 

a.  Initialization  - This  section  processes  the  user's 
punched  card  input.  It  uses  the  PMS  control  card 
to  deternine  which  PM  functions  are  to  be  perforned 
and  sets  up  a run  coanunication  record  to  control 
processing  for  the  run.  It  will  also  process  any 
segaent  control  cards  and  update  the  segaent 
records  on  the  data  file.  It  constructs  a disk 

work  file  fron  the  user's  Logic  Stateaent  Library 

« 
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update  cards;  if  there  are  any  card  transactions, 
these  are  output  to  a second  work  file. 

b.  L2ai£_Stat£*£fli_Coi£ilati2tt_aad_LibLiLi_!iain£.enance 

- The  functions  of  this  section  consist  of  deleting 
specified  reports  and  statements  from  the  Logic 
Statement  Library,  adding  new  reports  to  the 
library,  and  compiling  and  adding  new  statements  to 
the  library  for  a given  file.  The  report 
information  records  and  the  logic  statements  are 
maintained  on  the  library  in  sequence  by  report  and 
statement  name.  Each  logic  statement  on  the 
library  contains  two  parts.  The  first  part  is  a 
logic  statement  control  record  that  is  used  during 
transaction  processing.  This  record  indicates  the 
statement  type.  If  it  is  an  EXCEPTION  or 
SUBSET  EXCEPTION  statement,  it  indicates  the 
location  of  the  transaction  control  fields  in  the 
transaction  record  it  processes.  The  second  part 
consists  of  the  Executable  Load  nodule  that  is 
produced  when  the  POOL  language  or  NFL  statements 
are  compiled. 

In  addition  to  updating  the  Logic  Statement 
Library,  this  section  also  produces  a listing  of 
the  user*s  Logic  Statement  Library  update  deck, 
with  any  errors  flagged.  When  the  compile-only 
mode  of  PM  is  specified,  the  Logic  Statement 
Library  is  only  updated  by  the  addition  or  the 
deletion  of  reports/statements . For  compiled 
statements,  only  the  error  listing  is  produced. 

c.  Transaction  Processing  - The  Transaction  Processor 
matches  each  transaction  record  with  its 
appropriate  logic  statement  and  creates  an  update 
record  for  each  transaction  that  is  used  by  the 
File  Processing  section  to  perform  the  actual 
record  update. 


After  the  Transaction  Processor  reads  a transaction 
record,  it  extracts  the  transaction  ID  fields  from 
the  record.  The  locations  of  the  transaction  ID 
fields  are  associated  with  the  transaction  report 
name  on  the  Logic  Statement  Library.  It  then  uses 
the  transaction  report  name  and  the  transaction  ID 
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to  retrieve  the  control  record  of  the  logic 
stateaent  that  will  be  used  to  process  the 
transaction. 

An  update  record,  containing  the  naae  of  the  logic 
stateaent  that  processed  the  transaction,  a sort 
key,  and  the  transaction  record,  are  then  produced. 
The  high-order  byte  of  the  sort  key  contains  the 
update  record  type  indicator;  *H*  for  Range 
updates,  *E'  for  Exception  Range  updates,  and  'P* 
for  Exception  and  Direct  Subset  updates.  The 
collating  values  of  the  record-type  indicators 
establish  the  sequence  in  which  the  update  records 
will  be  passed  to  the  File  Processing  section,  but 
do  not  establish  the  sequence  in  which  the  update 
records  will  actually  be  processed.  For  Exception 
update  records,  the  sort  key  will  contain  only  the 
major  ID,  one  byte  of  binary  zeros  for  the  set 
nuaber  and  user  control  information.  For  direct 
subset  updates,  the  sort  key  will  contain  the  major 
ID,  the  set  nuaber  and  the  subset  control  field. 
The  remainder  of  the  sort  field  will  be  padded  with 
binary  zeros. 

At  the  completion  of  transaction  processing,  the 
update  records  are  ordered  on  the  sort  key,  if  they 
are  not  already  in  sequence. 

If  the  data  file  is  a segmented  file  and  segment 
processing  is  to  be  performed,  the  update  record 
sort  keys  are  checked  to  determine  if  the  record 
key  is  within  the  boundaries  of  the  segment  being 
processed.  If  it  is  not,  an  error  message  will  be 
printed  and  the  update  record  will  be  bypassed. 

d.  File  Processing  - The  Range  and  the  Exception  Range 
update  records  are  read  and  saved  in  core.  Then 
processing  of  the  Exception  and  Direct  Subset 
update  records  begins.  Direct  Subset  updating  for 
a given  record  will  be  performed  following  the 
exception  updates  on  the  record.  If  only  Direct 
Subset  updating  is  to  be  performed  on  the  record, 
the  fixed  set  and  the  subset  are  retrieved,  and  the 
updating  is  performed.  If  no  matching  fixed  set  is 
found,  an  error  message  is  logged.  When  a matching 
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subset  is  not  found,  a new  subset  is  generated,  and 
a 'NEW  RECORD'  switch  is  set  that  can  be  tested  by 
the  user  with  the  POOL  • BNR'  instruction  or  the  NFL 
new  record  test. 

If  Range  updates  are  to  be  made,  the  entire  data 
file  is  passed  sequentially.  As  each  data  file 
record  is  read,  its  record  key  is  Batched  against 
the  current  update  record's  sort  key.  If  a match 
is  found,  the  appropriate  logic  stateaent  is 
executed,  and  the  current  data  record  is  updated 
with  the  information  in  the  current  update  record. 

A new  update  record  is  then  read  and  processing 
continues  on  the  same  data  record,  until  an  update 
record  is  read  with  a different  sort  key.  At  this 
point.  Range  processing  is  executed  against  the 
current  record. 

If  the  current  update  record's  sort  key  has  a lower  J 

value  than  the  current  data  record's  key,  a new 
record  is  generated,  and  the  ne.w  record  switch  is 
set. 

If  the  current  data  record's  key  has  a lower  value 
than  the  current  update  record's  sort  key,  this 
indicates  that  no  exception  processing  is  to  be 
performed  against  the  data  record,  and  only  the 
range  processing  is  performed. 

When  Range  processing  is  performed  against  the 
records  that  were  not  updated  by  exception 
processing,  the  Exception  Range  logic  statements 
are  not  executed. 

When  all  of  the  data  records  and  update  records 
have  been  processed,  the  RANGE  statements  and 
EXCEPTION  RANGE  statements  that  have  been 
collecting  summary  information  are  executed  once 
more,  to  allow  them  to  output  the  information. 

When  no  Range  processing  is  required,  the  File 
Processing  Section  retrieves  and  processes  only 
those  records  with  keys  that  match  the  Exception 
update  record  sort  keys.  When  no  match  is  found, 
a new  record  is  generated. 
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e. 


File  generation  is  accomplished  by  generating  a nev 
record  for  each  Exception  update  record  with  a 
unigue  sort  key. 


Subset  Exception  updates  can  be  processed  during 
file  generation  for  those  records  generated  by 
Exception  update  records. 

For  sequential  processing,  the  file  is  passed 
sequentially  as  for  Range  updating.  The  FFT  and 
logic  statement  records  are  copied  onto  a new 
sequential  output  data  file.  The  records  are  read 
and  updated,  and  the  records  whose  major  IDs  have 
been  changed  are  written  on  a temporary  hold  file. 
This  hold  file  is  sorted  and  merged  with  the  output 
data  file  to  produce  the  new  data  file.  If  the 
sequential  file  is  a segmented  file,  a listing  of 
the  segment  control  records  on  the  data  file  will 
be  printed  indicating  segment  boundaries  and  the 
volume  serial  number  of  each  segment.  During  logic 
statement  execution,  if  a major  control  field 
change  occurs,  the  new  Record  ID  is  checked  to 
insure  that  the  new  ID  is  within  the  segment 
boundary.  If  the  new  Record  ID  is  not  within  the 
segment  boundary,  an  error  message  will  be  printed 
and  the  change  will  not  be  executed. 


A secondary  function  of  the  File  Processing  section 
is  the  production  of  a consolidated  auxiliary 
output  file.  The  records  for  this  file  are 
produced  when  any  of  the  POOL  or  NFL  instructions 
that  produce  printer,  punched  card,  or  tape 
auxiliary  output  are  executed.  Control  is  then 
passed  to  the  next  section. 

AUXjUac*  Output  Processing  - This  phase  reads  the 
consolidated  auxiliary  output  file,  and  outputs  the 
individual  records  to  their  proper  printer,  punched 
card,  disk  or  tape  files.  When  two  printer  files 
are  requested,  they  are  produced  sequentially  on 
the  sane  printer.  The  two  punched  card  files  are 
punched  into  pockets  1 and  2 of  the  card  punch. 
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Section  4 


INPUTS 


4.1  Card  Input 

Card  input  to  the  PM  component  consists  of  the  FMS 

control  card,  the  Logic  Statement  Library  update  deck,  and 

the  transaction  deck. 

4.1.1  FMS  Control  Card 

The  foraat  of  the  FMS  control  card  is  described  in 
sections  6.1.1  (Free-Foraat)  and  6.3.1  (Fixed-Poraat) . 

An  FMS  control  card  aust  be  the  first  card  in  the  FH  run 
deck.  It  specifies  the  functions  to  be  perforaed  during  the 
PM  run. 


4. 1.1.1  LIMIT  Control  Card 

The  foraat  of  the  LIMIT  control  card  is  described  in 
section  6. 1.1.1  (Free  Foraat).  The  LIMIT  control  card  is 
optional.  When  used,  it  aust  follow  the  FMS  control  card. 
It  specifies  the  range  of  records  that  File  Maintenance  will 
process. 


4.1.2  Segaent  Control  Cards 

The  segaent  control  cards  will  direct  the  coaponent  to 
perfora  processing  of  the  segaent  records  on  the  data  file. 
The  segaent  control  cards  aust  appear  iaaediately  after  the 
FMS  control  card.  If  segaented  processing  is  not  desired, 
these  cards  aust  be  oaitted.  The  foraat  of  these  cards  is 
described  in  section  6.1.2. 
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4.1.3  Logic  Statement  Library  Update  Deck 

This  deck  specifies  the  aaintenance  actions  to  be 
perforaed  on  the  Logic  Stateaent  Library  and  consists  of  the 
cards  discussed.  If  no  Logic  Stateaent  Library  update  is 
desired  on  a given  run,  there  is  no  reguireaent  for  this 
deck. 


4.  1.3.1  Library  Action  Cards 

The  fornat  of  the  library  action  cards  is  discussed  in 
sections  6.1.3  (Free-Foraat)  and  6.3.2  (Fixed-Format). 

These  cards  direct  the  component  to  perform  a specific 
type  of  library  update.  Each  library  action  card  may  be 
used  to  specify  one  update  action  only.  The  types  of 
updates  that  may  be  specified  are  as  follows: 


a.  Add  a Report  Name  - The  component  adds  the  report 
name  and  information  concerning  the  report  to  the 
library.  The  name  of  a report  must  be  added  to  the 
library  before  statements  which  will  be  used  to 
process  that  report  can  be  added  to  the  library. 
This  can  be  accomplished  in  one  pass  if  both  sets 
of  control  cards  are  in  order  in  the  same  run  deck. 


b-  i&!£il£_aad_Add_a_logi£_Stataioat_Ee£jSaaentl2  . The 

component  compiles  a logic  statement  and  adds  the 
logic  statement  to  the  library. 

c.  £21£ile_aad_Aii_a_L23i£_Siat£ign.t_leiEO£a£ily  - The 
component  compiles  and  adds  a logic  stateaent  to  a 
Temporary  Library  only  for  the  current  run.  A 
statement  added  temporarily  will  be  the  one 
executed  during  the  run  in  which  it  is  added,  even 
if  another  stateaent  with  the  same  name  already 
exists  on  the  Logic  Stateaent  Library. 


d. 


Kif*  - The  component  deletes  from  the  library  all 
of  the  report  information  and  logic  statements  that 
pertain  to  the  file. 


e.  Delete  a Report  - The  component  deletes  the 
specified  report  from  the  library  and  deletes  the 
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logic  statements  that  are  used  to  process  that 

report.  If  user  wishes  to  delete  more  than  one 

report  fro*  a file,  all  SDR  cards  should  be 
together  in  the  deck. 

f.  Delete  a Stateaent  - The  coaponent  deletes  the 

specified  stateaent  froa  the  library.  If  user 

wishes  to  delete  wore  than  one  logic  stateaent  froa 
a library,  all  $DS  cards  should  be  together  in  the 
deck. 

Note:  Each  library  action  card,  which  specifies  that  the 

coaponent  is  to  coapile  a stateaent,  aust  be  the  first  card 
of  the  logic  stateaent  deck  that  is  to  be  coapiled.  All 
other  library  action  cards  must  be  placed  in  front  of  the 
logic  stateaent  decks. 


4.  1.3.2  Logic  Statement  Source  Decks  ) 

Each  logic  stateaent  source  deck  consists  of  the  cards 
that  are  required  to  compile  and,  if  desired,  add  one  logic 
stateaent  to  the  library.  A maximum  of  24  logic  stateaent 
decks  aay  be  coapiled  and  added  to  the  library,  either 
teaporarily  or  peraanently,  during  an  FM  run.  There  is  no 
liait  on  the  total  nuaber  of  stateaents  that  aay  be  used 
with  a file  or  report. 

Each  logic  stateaent  aay  consist  of  the  following  card 
types: 

a.  Library  Action  (LAI  Cfrrd  - In  addition  to  directing 
FM  to  coapile  and  add  a stateaent  to  the  library, 
this  card  also  provides  information  about  the 
transaction  data  that  is  to  be  processed  with  the 
statement  to  be  coapiled.  If  there  is  no 
transaction  data  to  be  processed  by  the  stateaent, 
the  statement  is  not  added  to  the  library,  but  is 
coapiled  only  for  use  with  the  run  in  which  it  is 
coapiled.  The  foraat  of  the  LA  card  is  discussed 
in  sections  6.1.3  (Free- Foraat)  and  6.3.2  (Fixed- 
Foraat) . 

b.  Transaction -Descriptor  _ (TQ\,  - TD  cards  are 

used  to  describe  the  transaction  data  which  the 


22 


1 


FILE  MAINTENANCE  (FM) 


s statement  is  to  process.  They  provide  the  user 

with  the  capability  of  labeling  transaction  fields 
so  that  he  nay  reference  the  fields  by  labels  in 
language  source  statements.  These  mnemonics  need 
not  be  unique  froa  file  field  aneaonics. 

The  TD  cards  are  also  used  to  specify  the  locations 
of  the  transaction  control  fields.  If  transaction 
control  fields  are  not  specified,  the  component 
assumes  that  a Fange  statement  is  being  compiled. 

The  format  of  the  TD  card  is  discussed  in  sections 
6.1.3  (Free-Pormat)  and  6.3.3  (Fixed-Format). 

c.  Language  Identifier  C^rd  - This  card  must  precede 

the  POOL  and  NFL  source  statements.  The  format  of 
the  language  identifier  card  is  described  in 

section  6.1.4.  This  card  tells  the  compiler  which 
source  language  is  being  used. 

d.  Language  Source  St.atgmgpt  Ca^d  - Section  7 

discusses  the  format  and  logical  capabilities  of 
the  POOL  language,  and  section  9 discusses  the 

format  and  logical  capabilities  of  the  NFL.  The 
source  statement  cards  specify  the  processing  logic 
used  by  the  component. 

e.  Statement  END  Card  - The  last  card  in  each  logic 
statement  deck  must  be  a statement  END  card.  The 
format  of  this  card  is  discussed  in  section  6.1.5. 

4. 1.3.3  Logic  Statement  Library  Update  Terminator  Card 

The  last  card  of  the  Logic  Statement  Library  update  deck 
must  be  a terminator  card  if  card  transactions  follow  the 


deck.  The  format  of  this  card  is  described  in  section 
6.1.7.  This  card  is  required  only  if  library  updates  are  to 
be  performed. 

4.2  Transactions 

The  transaction  file  can  be  either  cards,  tape,  or  disk 
(sequential  or  indexed  sequential  or  VSAN  data  set)  or  a 
combination  of  multiple  sources  with  the  varying  data 
attributes.  If  it  exists  soley  on  cards  or  is  a combination 
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of  more  than  one  source,  it  aust  follow  the  Logic  Statement 
Library  update  terainator  card.  The  transactions  aay  be  of 
■ore  than  one  report  type  for  an  FN  run.  Normally,  the 
report  type  used  for  a run  is  entered  on  the  FH  control  card 
as  a parameter.  However,  for  runs  consisting  of  lore  than 
one  report  type,  the  transactions  applicable  to  the 
different  reports  gust  be  batched  separately  and  each  batch 
■ust  be  preceded  by  a report  identifier  card.  When 
utilizing  aore  than  a single  transaction  source  in  an  FH 
run,  a report  identifier  card  is  required  for  each  source  in 
order  to  provide  FH  with  the  transaction  DD  naie.  The 
foraat  of  the  report  identifier  card  is  discussed  in  section 
6.1.8.  Detailed  information  concerning  processing  of  a NIPS 
360  FFS  data  base  as  transaction  input  is  contained  in  the 
appendix  of  this  manual. 

Transaction  records  aust  follow  the  following 
conventions: 

a.  Each  transaction  record  aay  contain  one  variable 
field  which  must  be  the  last  field  in  the  record. 

b.  The  aaxiaua  size  of  the  transaction  record  is  1,999 
characters. 

c.  The  transaction  records  aust  be  in  one  of  the 
standard  S/369  foraats;  fixed  or  variable  length, 
blocked  or  unblocked,  or  undefined.  If  the  record 
foraat  of  the  transaction  is  either  variable  or 
undefined,  there  will  be  a 4-byte  field  prefixed  to 
the  beginning  of  the  transaction.  This  field  aust 
be  accounted  for  in  the  user's  logic  statement, 
i.e.,  if  the  logic  statement  name  starts  in 
position  1 of  a fixed  transaction,  then  it  will 
start  in  position  5 of  a variable  or  undefined 
transaction  (assuaing  the  saae  transaction, 

d.  A transaction  field  that  is  used  by  the  logic 
statement  as  an  indirect  address  aust  contain  a 
valid  field/group  naae  froa  the  file  foraat  table 
of  the  file  to  he  processed.  The  trhnsaction  aay 
contain  aore  than  one  indirect  address  field, 
however,  each  field  aust  contain  a valid  FFT 
field/group  naae. 
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Nuaeric  transaction  data  will  be  processed  in  two 
different  ways,  depending  on  the  use  to  be  eade  of  it.  (1) 
If  the  data  is  to  be  aoved  to  a binary  area  (that  is,  a 
binary  data  file  field  or  a binary  work  area)  or  if  it  is 
the  operand  of  a nuaeric  instruction  (i.e.,  add,  divide, 
aultiply,  subtract,  or  coapare  nuaeric  operands),  the  data 
will  be  righ^-ius^ifjfd  (i.e.,  trailing  blanks  will  be 
deleted)  and  "edited.  ~ Editing  aeans  that  all  characters 
between  the  ♦ and  - signs  (if  present)  and  the  last  non- 
blana  character  of  the  data  will  be  checked  to  aake  sure 
they  are  nuaeric.  The  last  character  will  automatically  be 
considered  nuaeric  if  it  can  be  converted  to  binary.  (2)  If 
the  data  is  to  be  aoved  to  a deciaal  area  (a  deciaal  file 
field  or  the  EBCDIC  work  area),  a check  will  be  aade  for  a 
♦ sign  or  - sign.  The  sign  will  be  replaced  in  the 
receiving  field  by  an  EBCDIC  zero;  a - sign  will  cause  the 
low-order  zone  of  the  receiving  field  to  be  aade  sinus.  The 
data  will  not  be  right- justi fied  or  edited  in  this  case. 
The  nuaeric  portion  of  each  byte  will  be  transferred  to  the 
receiving  area,  and  the  zone  portion  of  each  byte  except  the 
last  will  be  set  to  a hexadeciaal  *P'.  The  low-order  zone 
will  always  be  set  to  a hexadeciaal  *D'  (i.e.,  ainus)  if  the 
operand  contained  a ainus  (-)  sign;  otherwise,  the  low-order 
zone  will  be  transferred.  The  zone  of  a low-order  blank 
will  be  set  to  hexadeciaal  'C'  (i.e.,  plus). 

4.3  Subroutine  Library 

The  Subroutine  Library  aust  contain  all  subroutines  and 
tables  which  will  be  used  during  an  PH  run.  The  library  aay 
be  stored  on  the  sane  voluae  as  the  data  file  and  aay  have 
a naae  of  the  user’s  choice. 


4.4  Data  File 

The  FH  coaponent  processes  indexed  sequential  data  files 
on  disk  and  sequential  data  files  on  tape  or  direct  access 
devices.  The  FH  coaponent  will  also  process  Virtual  Storage 
Access  Method  (VSAN)  data  files  on  the  S/370.  When  desired, 
the  utility  prograa  UTflLDISH  (see  Voluae  VII,  Otility 
Support)  aay  be  used  to  load  sequential  data  files  onto 
direct  access  storage. 
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Section  5 


OUTPUTS 


5.1  Output  Data  File 

The  output  f cob  the  FM  component  is  a direct  access  data 
file,  updated  in  place  on  dish  (ISAM  or  VSAH  processing)  or 
a sequential  data  file  on  tape  or  disk  (SAM  processing) , or 
a segment  of  a sequential  data  file  on  tape  or  disk. 

5.2  Auxiliary  Output 

In  addition  to  producing  an  updated  data  file,  the  FM 
component  provides  the  user  with  the  capability  of  producing 
auxiliary  outputs  under  the  control  of  logic  statements. 
Auxiliary  output  aay  be  produced  on  disk.  Magnetic  tape, 
punched  cards,  or  the  printer,  according  to  the  user's 
formatting  specifications.  The  output  length  is  limited  to 
a maximum  of  99h  bytes.  NIPS  adds  six  overhead  bytes  to  the 
output  data  and  the  DCB  LF5CL  is  1000.  Violation  of  this 
limit  mill  cause  a System  001  ABEND  {I/O  EFFOF,  FBCOFD  TOO 
\ LONG)  . 

5.2.1  Tape  and  Disk  Auxiliary  Output 

During  an  FM  run,  the  user  nay  produce  auxiliary  output 
on  five  tape  or  disk  files. 

5.2.2  Punched  Card  Auxiliary  Output 

The  FN  component  provides  the  user  with  two  punched 
outputs.  Any  formatting  of  punched  output  must  be 
accomplished  by  the  user  in  his  logic  statements.  If  the 
user  requests  that  more  than  89  characters  of  data  be 
punched,  the  data  in  excess  of  89  characters  will  be  punched 
on  subsequent  cards. 
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5.2.3  Printed  Auxiliary  Output 

The  FM  component  provides  the  user  with  two  printed 
outputs.  The  user  is  responsible  for  foraatting  the  print 
lines.  The  FM  component  will  handle  the  printing  of  132 
characters  or  less.  If  the  user  requests  that  nore  than  132 
characters  of  data  be  printed,  the  data  in  excess  of  132 
characters  will  be  printed  on  subsequent  lines. 

5.3  Sun  History 

As  part  of  its  functioning,  the  FM  coiponent 
automatically  generates  a run  history  on  the  printer.  This 
includes  listings  of  logic  statements  that  are  compiled,  and 
messages  indicating  that  errors,  or  unusual  conditions  that 
might  be  interpreted  as  errors,  have  been  encountered  during 
processing. 

If  segmented  file  processing  is  being  performed,  the  J 

segment  control  records  on  the  current  segment  will  be 
printed  showing  the  segment  boundary  and  the  volume  serial 
number  of  each  segment. 

5.4  File  Analysis  and  Fun  Optimization  Statistics 

The  File  Analysis  Statistics  capability  in  the  FM 
component  provides  transactions  showing  the  number  of  times 
each  logic  statement  is  executed  during  an  FM  execution. 

The  data  set  name  (DSNAMF)  of  this  data  set  must  be  the  data 
file  name  suffixed  by  a T.  The  T is  added  to  ISAM  and  VSAM 
names;  the  S is  replaced  by  T in  SAM  names.  To  obtain 
transaction  output,  the  DSNAHE  must  be  cataloged  and  the 
user  must  specify  the  volume  serial  (VTRANS)  and  unit 
(UTBANS)  in  the  execution  procedure.  The  volume  may  be  any 
direct  access  volume. 

If  the  transaction  data  set  exists  at  execution  tine, 
transactions  will  be  added  (DISP*MOD) . If  the  data  set  does 
not  exist,  a 5-track  data  set  will  be  dynamically  allocated. 

The  user  may  change  the  allocation  value  by  overriding  the 
TRANST  00  card  space  parameter.  Transactions  are  written  as 
fixed  length,  unblocked,  50-byte  records.  The  format 
(fixed)  and  length  (50)  cannot  be  changed  but  the  user  nay 
change  the  blocking  factor  by  specifying  a DCB  BLKSIZE  in 
the  TRANST  00  card  which  is  a multiple  of  50. 
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If  the  user  specifies  a DSNANE  (TRANS)  in  the  TRANS  DD 
card,  he  Bust  supply  all  parameters  required  to  process  the 
data  set.  These  parameters  must  conform  to  the  requirements 
defined  above. 

The  Run  Optimization  Statistics  capability  provides  the 
user  with  statistical  data  reflectinq  the  core  allocation 
during  PH  execution.  The  breakdown  of  the  statistics  detail 
the  amount  of  core  used  for  user  subroutines  and  tables, 
logic  statements,  process  blocks,  I/O  buffers,  and  access 
methods.  It  also  includes  the  number  of  BLDL  entries 
allocated  and  used  and  the  number  of  entries  required  for 
each  subroutine,  table,  and  logic  statement  to  reside  in 
core.  The  amount  of  core  required  for  each  subroutine, 
table,  and  logic  statement  to  reside  in  core  is  also  output. 
If  subroutines,  tables,  and  logic  statements  are  rolled, 
this  information  will  be  output  with  the  causes  for  the 
rolling  and  the  number  of  times  it  occurred. 

In  addition,  the  user  is  able  to  enter  override 
parameters  for  the  number  of  BLDL  entries  to  allocate,  and 
the  size  of  the  processing  block  desired  for  storage  of  the 
data  records  during  PH  processing. 

The  statistics  gathering  is  initiated  through  parameters 
entered  in  the  PARK  field  of  the  EXEC  card.  The  parameters 
and  their  functions  are  as  follows: 

ROS  - Indicates  that  run  optimization 

information  is  to  be  gathered  and  output. 

NOROS  - Indicates  that  optimization  processing  is 

to  be  omitted.  If  no  other  parameters 
are  coded,  this  parameter  should  be 
omitted  as  it  is  the  default. 

The  parameters  the  user  may  supply  to  tailor  his  core 
allocation  are  listed  below.  Using  these  parameters,  the 
Run  Optimization  Statistics  are  gathered  and  output  unless 
the  NOROS  parameter  is  used. 

TCP=NK  - The  N indicates  the  number  of  bytes 

requested  for  the  process  block  in  1000 
(K)  bytes. 
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TCB=n  * The  n indicates  the  nuaber  of  entries  to 

be  used  in  the  BLDL  list  for  SUBSUP,  the 
subroutine  supervisor. 

TCS  - This  parameter  indicates  that  the 

statistics  record  on  the  ISAM  or  VSAM 
data  file  is  to  be  used  to  coapute  the 
process  block  size.  This  paraaeter  aust 
not  be  used  with  TCP  and  vice  versa. 

For  a aore  detailed  description  of  the  capability  see 
Introduction  to  File  Concepts,  Voluae  I. 
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CONTROL  CARD  FORMATS 


6.1  Free-Format  Specifications 

This  section  specifies  the  preparation  requirements  for 
all  FM  control  cards.  These  cards  may  be  punched  in  free 
format  or  fixed  format  (see  sections  6.1  and  6.3 
respectively) . 

The  general  rules  that  apply  to  free-fornat  control 
cards  are  as  follows:  J 

a.  The  control  card  data  must  always  be  punched 
starting  in  column  1.  The  first  character  of  a 
control  card  must  always  be  a dollar  sign  ($)  . 

b.  The  information  in  the  cards  must  be  punched  in  a 
specified  parameter  sequence. 

c.  The  control  card  fields  must  be  separated  by 
commas,  with  no  intervening  blanks. 

d.  If  the  analyst  has  no  requirement  for  a certain 
parameter,  he  must  so  indicate  by  punching  a comma 
for  that  field,  except  when  he  has  no  more  fields 
to  punch. 

The  four  control  cards  that  may  be  formatted  in  this 
manner  are  as  follows: 

a.  The  FMS  control  card 

b.  The  LIMIT  control  card 

c.  The  Library  Action  card 

d.  The  Transaction  Descriptor  card. 
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The  specifications  for  each  of  these  cards,  together  with  a 
description  of  the  editing  procedures  that  will  be  performed 
by  the  system,  follow.  Any  errors  detected  while  editing 
these  cards  will  cause  a no-go  switch  to  be  set.  However, 
all  control  cards  will  be  edited  before  any  run  which  has 
erroneous  control  cards  is  aborted. 

6.1.1  FMS  Control  Card  ( Free-Foraat) 

Description: 

Field  1 - $FMS/AAA-$Card  Identifier  And  Fun  Mode. 

$FMS/  is  the  card  identifier.  AAA  indicates  the 
run  node  and  nay  be  one  of  the  following: 

COM  - Logic  stateaent  coapilation  node.  The  input 
logic  statenent.s  will  be  conpiled  and  check  list 
generated.  No  library  actions  can  be  perforaed 

LIB  - Logic  Statement  Library  update  aode.  Logic 
statements  can  be  compiled,  and  all  library  actions 
can  be  performed  in  this  aode. 


Note:  For  sequential  files,  a run  node  of  COM  or 
LIB  will  cause  only  compilation  to  be  perforaed. 
No  library  action  will  be  accomplished. 

GEN  - Data  file  generation  node 

UPD  - Data  file  update  mode. 

Note:  Logic  statements  may  be  conpiled  and  added  to 
the  Logic  Statement  Library  with  file  generation  or 
file  update. 
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Field  2 - Pile  Name 

This  field  oust  contain  a 1-  to  7-character  file 
name.  The  first  character  must  be  alphabetic,  and 
no  embedded  special  characters  may  occur.  On  a SAM 
run  or  an  ISAM  or  VSAM  GEN  run,  this  field  supplies 
the  name  for  the  new  file. 

The  following  parameters  (fields  3-6)  are  only  used  if 
the  GEN  or  UPD  run  modes  are  specified.  If  the  COM  or  LIB 
modes  are  specified,  the  remaining  fields  should  be  omitted. 

Field  3 - Report  Name  (Optional). 

This  parameter  may  be  one  to  seven  characters  in 
length  and  must  be  alphabetic.  It  provides  FH  with 
the  name  of  the  first  transaction  report  that  will 
oe  processed  in  the  run.  This  parameter  may  be 
omitted  if  there  are  no  transactions  to  process,  or  i 

if  the  report  name  for  the  first  set  of 

transactions  is  to  be  specified  using  the  report 
identifier  card.  This  parameter  must  be  omitted  if 
the  transactions  being  processed  originate  from 
multiple  transaction  sources  as  information  as  to 
the  source  must  be  supplied  through  NEW  REPORT 
control  card  parameters. 

Field  4 - Logic  Statement  Library  Update  Indicator 

(Required  for  UPD  or  GEN  when  logic 
statements  are  to  be  compiled  on-line) . 

'LS'  indicates  the  library  is  to  be  updated.  This 
parameter  is  omitted  if  no  update  is  required. 

* Field  5 - Data  File  Type 

For  GEN  mode,  the  data  file  type  parameter  on  the 
FNS  control  card  should  be  supplied.  If  it  is  not 
supplied,  a default  option  is  used. 

For  UPD  mode,  the  data  file  type  parameter  on  the 
FMS  control  card  may  be  omitted.  The  default 
option  will  be  used  if  the  parameter  is  not 
1 , supplied. 
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The  data  file  type  parameters  are: 

TAPE  - Por  sequential  processing  (SAM) 

DISK  - Por  direct  access  processing  (ISAM  or  VS AH) 

The  default  option  is  to  process,  according  to  the 
organization  of  the  input  data  file  which  contains 
the  PFT,  logic  statements  and,  for  UPD  runs,  data 
records. 


Field  6 

TAPE  - 

DISK  - 

SAM  - 

ISAM  - 

CARD  - 


Transaction  Source  (Required  for  OPD  or 
GEN  Mode) 

Sequential  transactions;  file  on  either 
tape  or  direct  access  storage. 

Transaction  source  is  in  indexed 
sequential  organization 

Transaction  source  is  a NI^s  360  FPS  ISAM 
or  VSAH  data  file  in  sequential 
organization 

Transaction  source  is  a NIPS  360  P*S  data 
file  in  index  sequential  organization 

CARD  must  be  specified  or  this  parameter 
omitted  entirely  when  utilizing  multiple 
transaction  sources  since  the  NPH  REPORT 
card  describing  the  source  must  be 
included  in  the  run  deck. 


NONE  - No  transactions 


If  this  parameter  is  omitted,  CARD  is  assumed. 


Pield  7 

SEG  - 

NOSEG  - 


Segmented  Pile  Processing  Indicator 

Segmented  processing  to  be  performed  in 
this  run 

Bypass  segmented  file  processing  in  this 
run 
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If  this  parameter  is  omitted,  the  default  option  is  to 
perform  segmented  file  processing  if  the  data  file  is  a 
segment  and  to  ignore  segmented  file  processing  if  the  file 
is  not  a segment. 


6.  1.1.1  LIMIT  Control  Card 
Description: 

Field  1 - SLIMIT  - card  identifier 

Field  2 - Field  name  or  Group  name  [m/n]  [ #SUBTAB ] 

The  field  or  group  name  specified  must  include  the 
high-order  character (s)  of  the  major  control  field. 
The  user  has  the  option  to  specify  partial  field 
notation  for  the  field  or  group  by  indicating  m/n. 
This  specifies  which  portions  of  the  record  key 
will  be  used  for  comparison.  This  partial  field 
must  start  at  the  first  character;  i.e.  1/n.  In 
addition,  the  field  or  group  may  be  modified  by  a 
subroutine  expression.  Double  pound  signs  (*#) 
suppress  automatic  table  conversion,  and  the  name 
of  the  subroutine  enclosed  in  pound  signs  forces 
table  conversion. 

Field  3 - Relational  Operator 

The  relational  operators  shown  below  are  allowed  in 
the  statement  formed  by  the  LIMIT  operator  and 
condition  the  selection  of  records  as  follows: 

EQ  - process  when  egual  to 

LT  - process  when  less  than 

LE  - process  when  less  than  or  equal  to 

GT  - process  when  greater  than 

GE  - process  when  equal  to  or  greater  than 

BT  - process  when  equal  to  or  between 

The  logical  connector  NOT  nay  precede  all 
relational  operators. 
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Field  4 

- Literal(s) 

If  the  BT  relational  operator  is  specified,  then 
two  literals  are  required  and  must  be  separated  by 
a slash;  i.e.,  a/b. 

6.1.2 

Segaent  Control  Cards 

The  segment  control  cards  are  used  to  update  the  segment 
records  on  a segmented  data  file.  The  options  allowed  are 
as  follows: 

SEG 

This  option  indicates  to  the  component  that 
the  output  of  a GEN  run  is  to  be  a segmented 
data  file.  This  option  must  be  used  only  when 
the  mode  of  the  run  is  GEN. 

ADD 

This  option  indicates  to  the  component  that  a 
new  segment  record  is  to  be  added  to  the 
segmented  data  file.  This  option  may  be  used 
in  either  GEN  or  UPD  mode. 

REP 

This  option  indicates  to  the  component  that 
the  volume  serial  number  of  a specified 

segaent  is  to  be  replaced  by  a new  volume 
serial  number. 

DEL 

- 

This  option  indicates  to  the  component  that 
the  segaent  record  specified  by  the  low  key 

value  is  to  be  deleted  fro*  the  segmented  data 
file. 

Note:  The  actions  specified  by  the  segaent  control  cards 
will  be  performed  at  FH  initialization  tine.  Therefore,  if 
no  logic  statements  are  to  be  compiled,  oait  the  logic 
statement  parameter  on  the  PUS  control  card. 

The  control  cards  are  free  foraat  and  possible  operands 
are  as  follows: 

JSfiG  LOKET  HIKEY 

LOKEY  HIKEY  VOIID 

14£P  LOKEY  OVOLID  NVOLIO 
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IfiEL  LOKEY 

where  the  first  parameter  is  as  shown  - 

LOKEY  * the  lowest  aajor  control  field  for  the  segment 

HIKE!  * the  highest  eajor  control  field  for  the  segeent 

VOLIO  * the  volume  serial  nueber 

OVOLID  - old  voluee  serial  nueber  for  REP  action 

NV OLID  - new  voluee  serial  nueber  for  REP  action 

The  parameters  on  the  segeent  control  cards  eust  be 
separated  by  a coeea  and/or  one  or  eore  blanks.  If  the 
najot  control  field  contains  special  characters  or  blanks, 
the  field  eust  be  enclosed  in  quotes  or  at  signs.  More  than 
one  card  aay  be  used  to  specify  the  action  to  be  performed. 
However,  the  action  parameter  eust  be  ths  first  entry  on  the 
first  card  of  a set  of  cards  if  sore  than  one  card  is 
needed. 

Coluens  1-71  are  used  to  contain  the  segeent  parameter, 
column  72  is  used  as  the  continuation  column,  and  columns 
73-80  are  ignored. 

If  the  major  control  field  parameter  is  too  long  for  one 
card,  a nonblank  character  in  column  72  will  indicate  the 
continuation  of  the  field  in  column  1 of  the  next  card. 
Fields  specified  in  this  fashion  must  have  a single  quote 
(')  or  at  sign  (9)  at  the  beginning  of  the  field  and  a 
single  quote  or  at  sign  at  the  end  of  the  field.  A maximum 
of  four  cards  aay  be  used  in  specifying  one  field. 
Continuation  indicators  should  be  used  only  if  the  field 
continues  through  71  and  the  beginning  of  the  next  card. 

6.1.3  Library  Action  Card  (Free-Format) 

Description: 

Field  1 - Action  Identifier  (Required) 

This  field  must  contain  one  of  the  following: 
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JDF  delete  all  reports  and  statements  for 
a file 

JAR  add  a report  name 

SDR  delete  a report  name  and  all  statements 
for  the  report 
SDS  delete  a statement 
SASP  add  a statement  permanently 
SAST  add  a statement  temporarily. 

For  a SDP  card,  all  that  is  needed  is  the  action 
identifier-SDF. 

Field  2 - Report  Name 

This  field  is  used  to  specify  a report  name.  The 
report  name  may  be  from  one  to  seven  characters 
long.  It  is  required  for  all  action  cards  that 
deal  vith  reports  or  statements.  This  is  the  last 
field  that  need  be  specified  for  cards  with  the 
function  code  SDR. 

Fields  3,4,5  - Position  of  Transaction  Identification 
Fields  (Add  Report) 

The  Add  Report  card  is  treated  as  a special  case. 
Following  the  report  name,  it  will  contain  from  one 
to  three  parameters  used  to  specify  the  location  of 
transaction  identification  fields. 

The  format  of  this  parameter  is: 

HH-LL 

where 

H is  the  high-order  position  of  the  transaction  ID 
(or  a portion  thereof),  and  L is  the  low-order 
position  of  the  transaction  ID.  The  high-  and  low- 
order  positions  nay  be  specified  as  1-  or  2-digit 
numbers  with  a range  between  1 and  99.  A one- 
position  statement  ID  field  may  be  specified  by  one 
number  only. 
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Example: 


JAR, PORT, 1-3,80, 33-34 

This  card  requests  that  the  systea  add  inforaation 
about  report  type  PORT  to  the  library. 
Transactions  within  report  type  PORT  will  contain 
identification  in  three  fields.  Field  1 will  be  in 
coluans  1-3,  field  2 in  coluan  8 0,  and  field  3 in 
columns  33-34. 

The  following  fields  are  used  only  with  stateaent  action 
cards:  $AST, $ASP, $DS . 

Field  3 - Stateaent  Name  (Required) 

The  name  may  be  from  one  to  six  characters  long. 
No  embedded  blanks  will  be  permitted. 

If  the  library  action  specified  in  the  card  is  JDS, 
field  3 is  the  last  field  in  the  card.  The 
following  fields  pertain  only  to  the  add  stateaent 
cards. 

Field  4 - Length  of  Fixed  Transaction  Data 

(Reguired) 

This  field  nay  be  from  one  to  four  digits  long  and 
aust  b&  a number  between  1 and  1000  inclusive. 

Field  5 - High-Order  Position  of  Transaction 

Variable  Field  (Optional) 

If  no  variable  field  exists,  this  paraaeter  may  be 
omitted.  This  paraaeter  may  be  from  one  to  four 
characters  long  and  must  be  a number  between  1 and 
1000  inclusive.  The  value  of  this  paraaeter  aust 
be  greater  than  the  value  of  field  4. 


i 
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Field  6 - Exception  Range  Indicator  (OH  and  NFL 

only) 

This  field  contains  * XNP'  if  the  logic  statement 
being  compiled  is  an  Exception  Pange  statement.  If 
the  logic  statement  is  not  an  Exception  Pange 
statement,  this  parameter  must  be  omitted. 

Field  7 - NOP  Instruction  Count 

This  field  contains  ' NCT'  and  signals  to  the 
processor  program  that  the  test  for  logic  loops 
should  not  be  performed  during  the  execution  of  the 
logic  statement. 

6.1.4  Transaction  Descriptor  (TD)  Cards  (Pree-For mat) 

These  cards  are  provided  to  allow  the  user  to  label 
transaction  fields  in  writing  his  logic  statements.  He  may 
then  reference  the  transaction  field  label  in  his  logic 
statements  by  the  label  preceded  by  a dollar  sign  ($) . The 
format  of  these  cards  is  as  follows: 

Field  1 - Pield  Label  (Required) 

The  field  label  can  be  from  one  to  seven  characters 
long  and  must  be  preceded  by  a dollar  sign  (S)  . 
Both  alphabetic  and  numeric  characters  may  be  used, 
but  the  first  character  of  a label  must  be 
alphabetic.  No  special  characters  may  be  used. 

Field  2 - High-Order  Position  of  Field  in 

Transaction  (Required) 

This  field  may  be  from  one  to  four  digits.  If  the 
analyst  is  using  the  TD  card  to  assign  a label  to 
the  variable  field  of  the  transaction,  this 
parameter  will  be  the  last  parameter  on  the  card. 
In  this  case,  PM  will  make  certain  that  the 
position  specified  in  this  card  coincides  with  the 
high-order  position  of  the  variable  field  as  it  is 
specified  in  the  library  action  card. 

Field  3 - Low-order  Position  of  Transaction  Field 

(Required  Only  for  Fixed-Length  Fields) 
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This  field  aay  be  from  one  to  four  digits.  PM 
checks  to  aake  certain  that  the  value  specified 
here  is  not  greater  than  the  length  of  the  fixed 
field  as  specified  in  the  library  action  card. 

Field  4 - Major  or  User  Control  Pield  Designation 
(Optional) 

The  field  Bust  be  punched  as  a C followed  by  a 1- 
to  2-digit  nuaber  between  1 and  60.  The  nuaber 
indicates  the  seguence  in  which  the  transaction 
control  fields  must  be  arranged  in  order  to  conpare 
then  to  the  data  record  ID.  The  transaction 
control  fields  that  are  assigned  the  lower  seguence 
nuabers  and  that  have  an  aggregate  length  egual  to 
the  length  of  the  data  file  aajor  record  control 
group  constitute  the  aajor  transaction  control 
fields.  The  transaction  control  fields  that  are 
assigned  the  higher  seguence  nuabers  constitute  the 
user  control  fields;  they  are  not  used  in  Batching 
the  transaction  to  the  file  record  but  are  used  in 
sorting  to  control  the  record  update  seguence.  For 
exaaple: 


*RECID,4, 10, Cl 

This  exaaple  describes  the  transaction  field  which 
the  analyst  wishes  to  refer  to  as  PECID  in  his 
logic  stateaent.  It  is  located  in  positions  4-1? 
of  the  transaction,  and  it  is  the  aajor  portion  of 
the  transaction  that  corresponds  to  the  data  record 
ID. 

Field  5 - Data  Mode  of  the  Transaction  Field 

(Optional) 

A - Indicates  the  field  contains  alphabetic  data 

B - Indicates  the  field  contains  binary  data 

C - Indicates  the  field  contains  coordinate  data 

in  internal  foraat 

D - Indicates  the  field  contains  alphaaeric 

(EBCDIC)  data. 

If  this  parameter  is  oaitted,  D is  assuaed. 
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Field  6 - Control  Indicator  (Optional) 

This  parameter  specifies  the  type  of  control  field. 
The  following  codes  may  be  used. 

H - Major  control  field 
S - Secondary  control  field 
N - No  control  field. 

If  blank,  other  parameters  on  the  card  are  tested 
and  the  control  field  indicator  is  set  by  the 
program. 

Field  7 - Corresponding  Subset  Control  Pield 

Mnemonic 

This  parameter  specifies  the  subset  field  to  be 
used  as  a control  field  on  a direct  subset  update 
statement.  This  field  should  be  blank  for  other 
types  of  update  statements. 

6.1.5  Language  Identifier  Card 

This  card  will  contain  either  POOL  in  card  columns  16-19 
to  indicate  that  POOL  language  source  statements  follow  or 
NPL  in  any  three  consecutive  columns  to  indicate  that  NFL 
source  statements  follow. 

6.1.6  Logic  Statement  END  Card 

The  END  card  must  be  placed  at  the  end  of  each  POOL 
language  logic  statement.  This  card  will  contain  the  word 
EM D in  columns  16-18. 

6.1.7  Logic  Statement  Library  Update  Terminator  Card 

This  card  will  contain  the  word  STOP  in  card  columns  16- 
19.  The  STOP  card  must  be  the  last  card  of  the  logic 
statement  update  deck  if  card  transactions  follow  the  deck. 


6.1.8  Report  Identifier  Card 

This  card  is  used  to  signal  the  beginning  of  another 
report.  The  characters  NEW  REPORT  will  be  punched  in 
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columns  6-15.  The  report  name  will  begin  in  column  21  and 
may  be  from  one  to  seven  characters. 

If  processing  transactions  from  multiple  sources,  the  OD 
name  for  the  specific  transaction  source  must  follow  the 
report  name.  A comma  must  separate  the  report  name  from  the 
DD  name.  The  DD  name  must  be  in  the  form  PSTRANxx  for 
sequentially  organized  transaction  data  and  ISTRANxx  for 
defining  a NIPS  ISAM  or  V SAM  file  as  a transaction  source. 
The  xx  may  be  a user  coded  unique  ID  for  each  DD  statement. 
The  statements  must  be  included  by  the  user  immediately 
preceding  the  FN.SYSIN  DD  * at  run  execution.  Comments  may 
be  included  in  the  NEW  REPORT  identifier  card  following  the 
DD  name  after  allowing  a blank  to  separate  the  two.  NEW 
REPORT  statements  containing  the  optional  DD  name  parameter 
may  be  contained  only  in  the  SYSIN  data  set. . 


6.2  Ordinary  Maintenance  (OH)  Transaction  Descriptor 

(TD)  Cards 

The  PHS  control  card  and  library  action  control  cards 
must  be  coded  as  shown  in  sections  6.1,  6.1.1,  and  6.2.1. 

OM  Transaction  Descriptor  (TD)  cards  are  free  formatted 
(there  is  no  fixed  format  capability).  OM  TD  cards  may  not 
be  used  with  the  New  Pile  Maintenance  Language  (NFL).  The 
parameters  consist  of  keywords  followed  by  single  operands 
or  operanr?  lists.  Allowable  keywords  are  as  follows: 

FIELD 

CONTROL 

PICTURE 

VALUE 

RANGE 

VERIFY 

CONVERT 

GENERATE 

ERROR 

with  the  exception  of  the  FIELD  and  CONTROL  parameters,  the 
parameters  may  appear  in  any  sequence.  The  keywords  and 
operands  may  be  separated  by  any  number  of  blanks,  commas  or 
equal  signs.  Operands  that  contain  any  of  these  characters 
must  be  enclosed  in  single  quotes  (') . Operands  nay  not 
contain  quotes  in  any  position.  The  parameters  for  a single 
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transaction  field  nay  be  entered  on  any  number  of  cards. 
The  description  of  each  given  field  aay  begin  anywhere; 
however,  keywords  and  operands  nay  not  be  split  across  input 
card  boundaries.  The  nunber  of  characters  per  keyword 
operand  way  not  exceed  52.  The  total  number  of  characters 
per  keyword  operand  list  aay  not  exceed  9)79. 

Each  of  the  keyword  parameters  is  discussed  in  the 
following  subsection.  The  discussion  provides  a description 
of  each  keyword's  function,  the  legal  abbreviation  for  the 
keyword,  and  a description  of  any  restrictions  on  the  use  of 
the  keyword. 


6.2.1  Keyword:  PIELD 
Abbreviation:  FLD 

Example:  FLD  ALPHA  8 11  A J 

FLD  NUMBER  12  15  D 

Function: 

This  keyword  is  used  to  identify  the  start  of  a 
transaction  field  description  operand  list.  It  must  be  the 
first  parameter  on  a card.  The  FIELD  operands  must  be 
entered  in  a specific  sequence  as  follows: 

a.  User-assigned  transaction  field  mnemonic.  This  may 
be  a 1-  to  7-byte  alphameric  operand,  the  first 
byte  of  which  must  be  alphabetic.  When  the 
GENERATE  parameter  is  used,  the  transaction  field 
mnemonic  must  be  identical  to  the  mnemonic  for  the 
field  that  will  receive  the  data. 

b.  High-order  position  of  the  transaction  field.  This 
operand  may  be  from  one  to  four  bytes  long  and  must 
be  numeric. 

c.  Low-order  position  of  the  transaction  field 
(optional) . This  operand  is  omitted  for  variable 
length  transaction  fields.  The  operand  nay  be  from 
1-  to  4-nuneric  bytes  in  length. 
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d.  Field  notation  indicator  (optional) . This  field 
consists  of  a 1-byte  code  to  indicate  the  type  of 
data  contained  in  the  transaction  field.  The  legal 
codes  and  their  leanings  are  as  follows: 

'A*  - The  field  contains  alphaneric  data, 

including  blanks  and  special  characters. 

• B*  - The  field  contains  nuneric  data  in 
binary  fornat. 

•C*  - The  field  contains  coordina te  data 
in  internal  forn. 

' D*  - The  field  contains  nuneric  data  in 
decimal  format. 

The  default  option  for  this  code  is  'D*.  Deciaal  ('D*) 
transaction  data  nay  be  processed  in  the  POOL  language  by 
either  the  arithaetic  (MNO,  NNC,  CON)  or  logical  (MAL,  MAC, 
COA)  instructions. 


6.2.2  Keyword:  CONTROL 
Abbreviation:  CTL 
Exaaple:  CONTROL  PSCTL 

Function: 

This  keyword  is  used  to  specify  that  a transaction  field 
is  a control  field.  The  operand  aay  be  a 1-  to  2-digit 
nuaber,  to  indicate  that  the  transaction  field  is  a aajor  or 
record  control  field;  or  it  aay  be  a subset  control  field 
aneaonic,  which  indicates  that  the  transaction  field  is  a 
subset  control  field  for  a direct  subset  update  stateaent. 

For  aain  or  record  control  fields,  the  nuaber  indicates 
the  sequence  in  which  the  transaction  fields  are  to  be 
arranged  in  order  to  compare  then  to  the  data  record  ID. 
The  transaction  fields  assigned  the  lower  sequence  nuabers 
that  have  an  aggregate  length  equal  to  the  length  of  the 
aajor  data  record  control  group  constitute  the  aajor 
transaction  control  fields;  the  reaaining  transaction 
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control  fields  are  considered  user  control  fields,  and  are 
used  only  to  control  the  update  sequence  on  a given  record. 

when  the  control  parameter  is  specified,  it  gust 
immediately  follow  the  field  parameter  list. 


6.2.3  Keyword:  PICTURE 
Abbreviation:  PIC 

Exaaple:  PIC  A ABB  B*S  (A)  NN  A ( AB)  N 
Function: 

This  keyword  is  used  to  indicate  that  character  or 
profile  checks  are  to  be  performed  on  a transaction  field. 
The  keyword  should  be  followed  by  Masks  depicting  the  types 
of  EBCDIC  characters  peraitted  in  the  defined  transaction 
field.  The  PICTURE  paraaeter  may  only  be  specified  for 
alphaaeric  or  deciaal  transaction  fields.  Character  checks 
that  aay  be  specified  by  the  nasks  are  Alphabetic  (A)  , 
Nuaeric  (N) , Special  (S) , Blank  (B)  , Nonblank  (X),  Non- 
special (Y) , and  no  check  or  universal  natch  (*)  . 

A direct  test  for  specific  characters,  as  opposed  to 
types  of  characters,  aay  be  specified  with  a VALUE  check,  or 
by  enclosing  the  specific  characters  in  parentheses.  The 
picture  nasks,  not  counting  parentheses,  must  be  either 
shorter  than  or  equal  to  the  length  of  the  transaction  field 
defined.  If  a aask  is  shorter,  only  the  leftaost  characters 
of  the  transaction  field  will  be  checked,  up  to  the  length 
of  the  aask.  The  picture  aask  is  terainated  by  the 
occurrence  of  a blank.  Up  to  1?  nasks  aay  be  specified  in 
a PICTURE  paraaeter  list. 
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6.2.4  Keyword:  VALUE 
Abbreviation:  VAL 

Exaaple:  VAL  32768  8192  ***58  *AAbX3* 
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Function: 

This  keyword  indicates  that  the  transaction  field  data 
■ust  aatch  one  of  the  values  specified  in  the  operand  list 
that  follows  the  keyword. 

The  VALUE  paraaeter  nay  only  be  used  in  editing 
alphaneric  or  decimal  (Type  'A*  or  'D')  transaction  fields. 
The  values  specified  in  the  list  will  be  conpared  against 
the  transaction  data  by  left- justifying  the  list  values  and 
padding  with  blanks  as  required  to  achieve  field  length. 
Value  operands  nay  not  exceed  the  transaction  field  length. 

List  values  for  either  alphaneric  or  decimal  fields  nay 
contain  any  number  of  letters,  if  any  of  the  list  values 
contain  embedded  blanks  (b)  or  connas  (,)  , they  nust  be 
enclosed  in  single  quotes  (•).  if  any  of  the  list  values 
contain  any  other  special  characters,  they  need  not  be 
enclosed  in  quotes,  but  the  node  specification  of  the  field 
nust  be  alphaneric  (type  'A').  A universal  natch  character 
(*)  nay  be  used  to  indicate  positions  of  a transaction  field 
which  are  not  to  be  validated. 

Up  to  10  values  nay  be  specified  in  a VAL  parameter 
list.  Validation  against  more  than  ten  values  should  be 
performed  with  a table  or  subroutine  and  the  VERIFY  keyword. 


6.2.5  Keyword:  RANGE 
Abbreviation:  RAN 

Example:  RANGE  991  499  -1 9 29 

Function: 

This  keyword  is  followed  by  a list  of  alphaneric  value 
pairs  and  indicates  that  the  transaction  field  value  nust 
fall  within  the  range  of  at  least  one  of  the  specified  value 
pairs.  This  type  of  editing  nay  not  be  performed  on 
coordinate  (type  *C')  transaction  fields. 

All  value  pairs  nust  be  alphabetic  or  nuneric.  A ninus 
(-)  sign  nay  precede  a value  to  indicate  that  it  is 
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negative.  The  first  value  of  a pair  must  be  less  than  the 
second  value. 

For  binary  and  zoned  decimal  fields  (types  *B’  or  'D'), 
an  arithnetic  range  test  is  performed.  RANGE  operands  for 
these  field  types  may  not  exceed  10  characters  and  must 
contain  numbers,  or  numbers  preceded  by  a minus  sign. 

A logical  range  check  is  performed  on  alphameric  fields. 

Up  to  10  range  pairs  nay  be  specified  in  a RANGE  operand 
list. 


6.2.6  Keyword:  VERIFY 
Abbreviation:  VER 
Example:  VERIPY  SUBRS 

Function: 

This  keyword  will  be  followed  by  the  name  of  a single 
user-supplied  validation  subroutine  or  table.  It  indicates 
that  the  field  identified  by  the  TD  statement  is  to  be 
passed  against  the  data  validation  subroutine  or  table.  An 
indication  of  the  result  (valid/invalid)  is  to  be  returned 
to  the  system. 

Validation  or  conversion  subroutines  and  tables  should 
be  written  in  accordance  with  the  Users  Manual,  Volume  I, 
is  Ella  £2a£S2i§,  and  Volume  VII,  fltility 

Support. 


6.2.7  Keyword:  CONVERT 
Abbreviation:  CON 
Example:  CON  TABID 

Function: 

This  keyword  will  be  followed  by  the  name  of  a single 
user-supplied  data  conversion  subroutine  or  table  and 
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indicates  that  the  transaction  field  identified  by  the  TD 
card  is  to  be  passed  through  the  conversion  routine.  The 
result  is  stored  in  the  original  transaction  field,  left- 
justified,  with  trailing  blanks  to  the  length  of  the 
original  field.  The  result  length  must  be  equal  to  or 
shorter  than  that  of  the  original  transaction  field.  A 
validity  indicator  will  be  returned  to  the  system. 

Ground  rules  for  writing  conversion  subroutines  and 
tables  are  the  sane  as  those  specified  for  the  VERIFY 
parameter. 


6.2.8  Keyword:  GENERATE 
Abbreviation:  GEN 

Example:  FIELD  FLDNAM  5 10  A GENERATE 
Function: 

This  keyword  does  not  expect  or  require  any  operands. 
It  specifies  that  the  system  should  automatically  move  the 
data  from  the  transaction  field  to  the  data  field.  The  user 
name  specified  as  the  transaction  field  mnemonic  (reference 
the  FIELD  parameter)  must  be  identical  to  the  mnemonic 
assigned  to  the  file  field  to  be  updated. 

GENERATE  may  be  used  to  cause  updating  of  existing 
periodic  subsets,  when  it  is  used  with  direct  subset 
updating  logic  statements.  In  direct  subset  updating  logic 
statements,  the  user  specifies  the  location  of  the  subset 
control  fields  in  the  transaction  record  by  using  the 
control  parameters  on  the  appropriate  TD  cards.  If  no  file 
match  is  round  for  the  subset  control  fields,  a new  subset 
is  generated  and  the  new  record  switch  is  turned  *on» 
(unless  the  fixed  set  does  not  exist,  in  which  case  an  error 
message  will  be  logged).  The  user  may  interrogate  this 
switch  by  the  POOL  'BNR'  instruction  if  desired. 

This  keyword  may  also  be  used  to  create  new  periodic 
subsets,  when  used  in  exception  logic  statements  or  range 
logic  statements,  provided  that  the  periodic  subsets  do  not 
contain  user-defined  control  fields.  Each  execution  of  the 
logic  statement  will  cause  generation  of  new  subsets  at  the 
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end  of  each  set  to  be  updated.  When  there  is  no  file  aatch 
against  the  major  record  control  field,  a new  fixed  set  is 
automatically  generated.  The  new  record  switch  is  set  'on' 
and  aay  be  tested  by  the  POOL  ' BNR ' instruction,  if  desired. 

The  GEN  keyword  need  not  be  coded  for  fields  identified 
as  control  fields. 


6.2.9  Keyword:  ERROR 

Abbreviation:  ERR 

Exaaple:  ERR  T 

ERR  DS 

Function: 

This  keyword  expects  a single  parameter  to  identify  the 
error  option  to  be  taken  when  invalid  data  is  detected  in  a 
field  by  any  of  the  edit  functions  specified  by  the  TD 
paraaeters.  The  options  and  their  code  identifiers  are  as 
follows: 

£ODE  OPTION 

D Data  is  not  to  be  aoved  to  the  data  file. 

The  data  move  instruction  created  by  the 
GEN  parameter  for  the  transaction  field 
will  not  be  executed. 

B Blank  or  clear  the  receiving  data  file 

field.  The  data  field  is  set  to  its  null 
value  (blanks  for  alphameric  fields, 
zeros  for  numeric  and  coordinate  fields). 
The  option  nay  not  be  used  with  record 
control  fields. 

* Accept  the  data. 
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T Delete  the  transaction.  When  this  option 

is  used,  no  updating  will  take  place  with 
any  of  the  transaction  fields.  If  a new 
record  or  subset  has  been  created  by  the 
transaction,  it  will  be  deleted. 
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If  this  ERF  keyword  is  emitted,  the  default  option  is 
ERR  D.  If  the  ERR  keyword  is  specified,  it  must  be  followed 
by  a valid  code  identifier,  omission  of  the  code  identifier 
will  result  in  error  message  20036. 

As  transaction  data  errors  are  detected  in  processing 


specified  by  Ordinary  Maintenance  TD  cards 

, they  will 

be 

collected  and 

reported 

as  an  additional 

auxiliar  y 

output 

stream  during  FM 

e xecution 

. The  error  log 

format  will 

be 

as 

follows: 

ERROR 

MAJOR  KEY 

FIELD  ID 

ERROR  MESSAGES 

DATA 

ACTION 

(30  char,  max.) 

(50  char,  max.) 

(3p  char,  max.) 

CODE 

xxxxxxxxxxxxxxx 

xxxxxx 

xxxxxxxxxxxxxx 

xxxx 

X 

XXXXXXXXXXXX  XXX 

xxxxxx 

xxxxxxxxxxxxxx 

xxxx 

X 

The  standard 

error  messages  generated  indicate  the 

data 

validation  failure  as  specified  by  the  OM  keyword  parameter. 
Messages  are  as  follows: 

RANGE  ERROR 
VALUE  ERROR 
PICTURE  ERROR 
VERIPY  ERROR 
CONVERT  ERROR 

The  log  say  be  suppressed  for  a given  field  by  coding  an 
'S'  following  the  error  option  code. 

Tests  for  validity  of  a given  field  or  the  entire 
transaction  may  be  made  by  the  POOL  *BFV*,  *BTN • , 
•BTV'  instructions  (see  section  7.4.5).  User-defined  error 
messages  for  this  log  require  use  of  the  POOL  * ERR* 
instruction  (see  section  7.4.6). 

The  ordinary  Maintenance  error  log  capability  nay  also 
be  used  when  writing  logic  statements  for  the  Source  Data 
Autonation  (SODA)  on-line  maintenance  capability.  When  used 
on-line,  erroneous  data  is  logged  by  underlining  the 
erroneous  transaction  data  with  a key  to  the  message 
indicating  the  type  of  error  detected.  (See  Terminal 
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Processing  (TP)  Component,  Volume  VI  of  the  NIPS  360  FFS 
Users  Manual. 

6.3  Fixed-Format  Specifications 

The  FM  component  provides  the  user  with  the  option  of 
preparing  the  FM  control  cards  in  fixed-format,  so  that 
compatibility  may  be  maintained  with  the  1410  NIPS.  This 
format  is  somewhat  more  rigid  than  the  free-fornat  in  that 
the  data  fields  must  be  placed  in  certain  card  columns  and 
numeric  values  must  be  made  a specified  length  by  punching 
leading  zeros. 

One  format  or  the  other  must  be  used  exclusively  for  any 
given  run.  Fixed-format  control  cards  can  not  be  used  with 
Ordinary  Maintenance. 


i 


6.3.1  FMS  Control  Card 


Format: 

9 

1 

1 

2 

3 

4 

5 

b 

9 

6 

1 

9 

5 

0 

AAAA 

BBb 

CCCCC 

DDDDDD 

EEF 

FF 

GGGG 

Description: 
Field  A 
Field  B 

COM 


LIB 


Card  identification  (must  contain  FMS/)  . 

Run  mode  (must  contain  one  of  the 
following) : 

Compile  mode.  The  input  logic  statements 
will  be  compiled  only  and  a check  list 
generated.  No  statements  can  be  added  to 
the  library  in  this  mode.  However,  any 
other  library  actions  can  he  performed. 

Logic  Statement  Library  update  mode. 
Logic  statements  can  be  compiled,  and  all 
library  actions  can  be  performed  in  this 
mode. 
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Note:  For  sequential  files,  a run  node  of  COM  or  LIB 
will  cause  only  conpilation  to  be  performed.  No 
library  action  will  be  accomplished. 


GEN 

- 

Data 

file 

generate  mode 

UPD 

- 

Data 

file 

update  mode. 

Note:  Logic  statements  may  be  compiled  and  added  to 
tne  Logic  Statement  Library  with  file  generation  or 
file  update. 

Field  C - File  name.  The  file  for  which  all 

processing  specified  is  being  performed. 
A file  name  must  be  specified  in  this 
field. 

The  following  fields  (D  through  0)  are  left  blank  if  LIB 
or  COM  mode  is  selected. 

Field  D - This  field  is  used  to  specify  the  report 

name  for  the  first  set  of  transactions 
that  will  be  processed.  The  report  name 
may  be  from  one  to  six  characters  long 
and  must  he  left- justified . A report 

name  need  not  be  specified  in  this  field 
if  the  user  can  use  the  report  identifier 
card.  However,  when  the  user  is  updating 
with  tape  transactions,  it  is  quite  often 
more  convenient  to  specify  the  report 
name  here  than  to  try  to  generate  a 
report  identifier  card  image  on  his 
transaction  tape. 

Field  E - This  field  is  used  to  specify  the 
transaction  source. 

SIH  - Card  transactions. 

MFC  - Tape  transactions. 

BLANK  - Vo  transaction  data. 

Field  F LS  Indica*<»s  that  logic  statement 

compilation  or  Logic  Statement  Library 
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(pM) 

a 

1 

I 

maintenance  is  to  be  performed  during  the 
run. 

i 

BLANK  - No  logic  statement  compilation  or 

Logic  Statement  Library  maintenance  is  to 
be  performed. 

4 

Field  G 

DISK  - For  direct  access  processing  (ISAM 
or  V S A N)  . 

! 

TAPE  - For  sequential  processing  (SAM). 

{ 

t 

1 

6.3.2  Library 

Action  Cards 

1 

For«<it: 

i 

i 

9 9 1111  22  23  34  4 

1 fa  ? 2 56  01  5 ? 5?  5 

MNNNN  0000 AAA AACCCCC  DDDDDD  LLLLLL 

i 

| 

J 

> 

5 5 5 
9 2 5 
BBB  E 

6 

7 

EFFGGHHIT JJ  K 

| 

Description: 

i 

Field  A 

Card  Identification.  It  must  contain  the 
word  START. 

Field  B 

Action  Identification.  It  must  contain 
one  of  the  following  codes,  left- 

justified: 

DP  - Delete  all  reports  and  all 

statements  for  a file. 

1 

AR  - Add  a report  name. 

DR  - Delete  a report  name  and  all 

statements  for  a report. 

| 

1 r 

ASP  - Add  a statement  permanently. 

. 1 

AST  - Add  a statement  temporarily 

J 

i 
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DS  - D <=»  1 <=«-<=*  a statement. 

Field  C - File  Name.  It  must  contain  a 5-character 
alphabetic  file  name.  If  the  library 
action  card  is  being  used  to  add  a file, 
delete  a file,  or  request  compilation  of 
a Range  statement,  without  transaction 
data,  only  fields  A through  C need  to  be 
punched. 

Field  D - Report  Name.  This  field  contains  a 1-  to 
6-character  report  name,  left- justified . 

If  th®  library  action  card  is  being  used 
to  delete  a report,  field  n is  the  last 
field  that  need  be  punched. 

Fields  E through  K are  required  only  when  the  action 
code  is  Add  Report  (AR.)  . They  are  used  to  specify  the 
number  and  location  or  the  transaction  identifier  fields. 

At  least  one  and  up  to  three  identifier  fields  may  be 
specified  in  this  manner.  Each  location  is  specified  by  a 
pair  of  2-digit  numbers.  The  total  length  of  transaction  ID 
fields  may  not  ®xce®d  six  characters. 

Field  E - NN  - High-order  location  of  the  major 
(Reguired)  identification  field. 

Field  F - NN  - Low-order  location  of  the  major 

(Required)  identification  field.  4 I 

Field  G - NN  - High-order  location  of  the  second 
(Optional)  identification  field. 

Field  H - NN  - Low-order  location  of  the  second 

(Optional)  identification  field. 

Field  I NN  - High-order  location  of  the  third 

(Optional)  identification  field. 

Field  J NN  - Low-order  location  of  the  third 

(Optional)  identification  field. 

Field  K N - Number  of  transaction  ID  fields.  N 

(Required)  must  be  a number  between  one  and  three. 

1 ' 
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ihe  following  fields  are  used  only  when  compiling, 
deleting,  or  adding  a statement  to  the  library. 

Statement  Name.  This  field  contains  a 1- 
to  6-character  statement  identifier, 
left- justified . 

This  field  must  contain  a T,  indicating 
that  the  logic  statement  will  be  used 
with  transaction  data. 

NNNN-Length  of  the  fixed  portion  of  the 
transaction  data.  NNNN  must  be  a 
4-digit  number  net  greater  than  1,000 
with  leading  zeros  as  reguired. 

NNNN-High-order  position  of  the 
transaction’s  variable  field.  NNNN 
must  be  a 4-digit  number  with 
leading  zeros  as  reguired. 

BLANK  - No  variable  transaction  field. 


6.3.3  Transaction  Descriptor  (TD)  Cards 
Format: 

0 0 11  2223  333  34  4 55 

16  26  0140  345  7/0  5 02 

BBBBBBB  AAA AA  CCCC  DDDDEE  F GGGGGG  H IIIIIII 

Description: 

Field  A - Card  Identification.  It  must  contain  the 
word  FIELD. 


Field  L 


Field  M 


Field  N 


Field  O- 


J 


i 


l 


Field  B - Transaction  Field  Label.  Labels  nay  be 
from  one  to  seven  characters  in  length 
and  must  be  left- justified  in  this  field. 
The  following  roles  apply  to  transaction 
field  labels. 
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a.  They  aay  be  alpha  or  numeric 
characters,  but  they  east  begin 
with  an  alpha  character. 

b.  No  embedded  blanks  aa y appear  in 
a label. 

Field  C - NNNN-Transaction  Field  - High-crder 
position.  Must  be  a 4-digit  number,  with 
leading  zeros  as  required.  This  field 
aay  be  left  blank  on  a Transaction 
Descriptor  card  that  is  part  of  a set  of 
cards  that  are  being  used  to  describe 
contiguous  fields.  However,  if  this 
field  is  left  blank,  extreme  care  must  be 
taken  to  maintain  the  sequence  of  the 
cards.  If  the  Transaction  Descriptor 
card  is  being  used  to  assign  a label  to 
a variable  transaction  field,  field  C is 
the  last  one  that  need  be  punched.  The 
TD  card  for  the  variable  jfield  must  be 
the  last  card  in  the  Transaction 
Descriptor  deck. 

Field  D - NNNN-Transaction  Field  Length.  Must  be 
a 4-digit  number  with  leading  zeros  as 
required . 

Field  E - N-Transaction  Control  Field  Indication. 

If  the  transaction  field  is  part  of  the 
control  group,  N must  be  a 2-digit  number 
between  one  (01)  and  sixty  (60)  . A one 
indicates  that  the  field  contains  the 
major  control.  The  numbers  02  through  60 
are  used  to  indicate  the  minor  fields. 
If  a field  is  not  part  of  the  transaction 
control,  N must  be  blank  or  zero  (00)  . 

Field  P - Mode  of  Transaction  Field.  This 

parameter  specifies  the  mode  of  the 
field.  The  following  codes  aay  be  used. 

L 
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A - Alphabetic 
B - Binary 
C - Coordinate 
D - Alphameric 

If  omitted,  D is  assumed. 

Field  G * Statement  Name  (optional)  . This  field, 
if  used,  contains  the  name  of  the 
statement  being  processed. 

Field  H - Control  Indicator  (optional).  This  field 
specifies  the  type  of  control  field,  and 
may  contain  the  following  codes. 

« - Major 
S - Secondary 
* N - Not  control 

J 

♦If  this  parameter  is  omitted,  other  parameters  are 
checked  and  the  program  sets  the  control  indicator 
accordingly. 

Field  I - Corresponding  subset  field.  Por  a direct 
subset  update  statement  only.  This 
parameter  specifies  the  subset  field  to 
be  used  for  a control  field  on  a direct 
subset  update  statement.  It  must  be 
omitted  for  all  other  t^ypes  of 
statements. 


I 


J 

[ 


6.3.4  Language  Identifier  Card 
Format: 


9 1111 

1 6789 

AAAA 
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Description: 

Field  A - Language  Identification. 

POOL  - Indicates  POOL  language  source 
cards  follou. 
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Section  7 


POOL  LANGUAGE 


7.1  Card  Format 

The  format  of  POOL  coding  is  as  follows:  Each 

instruction  operator  is  coded  in  columns  16-18.  Operands 
begin  in  column  21.  If  any  instruction  is  labeled,  the 
label  will  appear  as  a mnemonic  in  columns  6-12. 

IS  1 2 

6 6 1 

SYMBOL  OPERATOR  OPER AN D A ,OPER ANDB,OPER ANDC ,OPER ANDD 

7.1.1  Symbols 

Instruction  symbols  may  be  from  one  to  seven  characters 
long.  The  first  character  must  be  alphabetic.  The 

remaining  characters  may  be  alphameric. 

7.1.2  Operators 

The  operators  specify  the  logical  functions  to  be 
performed.  These  are  discussed  in  detail  in  section  7.3. 

7.1.3  Operands 

There  may  be  up  to  four  operands  per  instruction, 
depending  on  the  operator.  The  operands  are  separated  by 

commas  or  a single  blank.  The  types  of  operands  and  the 
coding  requirements  for  each  type  are  discussed  in  section 
7.2. 

7.1.4  Comments 

The  user  may  also  comment  on  his  instructions.  At  least 
two  blank  must  separate  the  comment  from  the  last  operand. 


FILE  MAINTENANCE  (EM) 


7.2  Operand  Coding 

The  operands  of  each  POOL  instruction  generally  specify 
fields,  indicators,  and  tags  upon  which  the  POOL  operator 
acts.  The  following  conventions  are  used  in  specifying  the 
operands: 

a.  Data File Fields  — Pields  of  a data  file  are 

indicated  by  the  actual  field  or  group  naae 
assigned  in  the  File  Poraat  Table  (FPT) . These  are 
denoted  by  one  to  seven  characters.  The  first 
character  aust  be  alphabetic,  and  the  field  nane 
■ust  not  contain  embedded  special  characters. 

b.  Transaction  Input  Fields — Transaction  input  fields 
(input  data  used  in  updating  the  data  base)  can  be 
identified  by  an  alphabetic  aneaonic  froa  one  to 
seven  characters  in  length,  prefixed  by  a dollar 
sign  ($) . The  transaction  field  naae  aust  be 
identified  by  aeans  of  a TD  card  (refer  to  sections 
6.1.3  and  6.2  or  section  6.3.3). 

The  transaction  field  nay  also  be  specified  by  the 
fora  Tn/n,  where  and  "n"  specify  the  high-  and 
low-order  positions  of  the  transaction  field  in  the 
transaction  record.  No  spaces  are  left  between  the 
characters  of  this  operand,  e.g.,  JITEM  or  THff/55. 

c.  Indirect  Designation--*  data  file  field  nay  be 
indirectly  designated  by  the  contents  of  the 
transaction  input  record.  In  this  case,  the  letter 
C prefixes  the  usual  operand  fora  for  the 
transaction  field  except  when  high-  and  low-order 
transaction  field  positions  are  specified.  In  this 
case,  the  C replaces  the  T,  e.g.,  C ST  RAN  or  C20/27. 
The  contents  of  the  transaction  field  aust  be  a 
data  file  field  or  group  naae  as  specified  in  the 
FFT. 

d.  Three  of  the 
POOL  aacro  instructions  have  an  operand  which 
controls  the  printing  of  error  aessages  when  an 
incorrect  or  invalid  value  is  processed  by  a 
table/subroutine.  When  an  invalid  input  is 
detected,  it  will  not  be  used  by  PN.  However,  if 
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the  value  ca  froa  a transaction  record,  the 
reaaining  dat»  will  be  used  as  specified  in  the 
logic  stateaent.  the  validity  codes  (C  operands) 
function  in  the  following  fashion: 


1 


► 


-4 


I 


Code  A 

or  R - When  the  input  data  is  invalid,  the 

data,  its  source,  and  an  error  aessage 
are  printed  on  the  run  history  file. 

Code  I - Ho  printing  occurs  in  event  of  an  error. 

e.  Instruction  Tads  — when  one  of  the  POOL  instructions 
specifies  a branch  to  another  instruction,  the 
operand  is  the  1-  to  7-character  alphabetic  tag 
assigned  to  the  branched-to  instruction. 

f.  Literals-- Literals  aay  be  used  as  operands  in  aost 
instructions.  The  literals  aay  be  alphabetic, 
signed  nuaeric  or  unsigned  nuaeric.  Alphabetic 
literals  are  enclosed  within  single  quotes.  All 
enclosed  literals  are  considered  alphabetic  if  any 
character  included  is  other  than  a valid  nuaeric 
character. 

Nuaeric  literals  do  not  need  to  be  enclosed  within 
single  quotes.  An  unsigned  nuaeric  literal  is 
considered  positive,  and  a signed  numeric  literal 
will  have  the  sign  set  in  the  low-order  byte  during 
processing . 

A signed  nuaeric  literal  enclosed  in  quotes  will 
cause  the  sign  to  be  carried  as  an  additional 
character . 

One  restriction  applies  to  the  use  of  alphabetic 
literals;  a single  quote  aay  not  be  embedded  in  a 
literal. 

g.  ggcpic  Work  Area  — FH  provides  a 999-byte  EBCDIC 
work  area  for  formatting  auxiliary  output  records, 
for  accuaulating  suaaary  inforaation  and  for 
passing  inforaation  between  logic  stateaents.  POOL 
instructions  will  reference  this  area  by  the 
operand  notation  WX/Y  where  X and  Y are  the  high- 


J 


» 
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and  low-order  locations  of  a work  area  field,  e.g., 
Hl/100  or  W299/239.  A maximum  of  994  bytes  aay  be 
specified  in  auxiliary  output  instructions  (e.g., 
POOL  PRT,  NFL  PRINT).  Violation  of  this  liait  will 
result  in  a System  001  ABEND. 

h.  Binary  Work  Area  — PH  provides  a second  work  area 
which  can  be  used  to  perform  arithmetic  functions 
in  binary.  This  area  will  be  29  words  (8(1  bytes) 
long.  POOL  instructions  will  reference  words  in 
this  area  by  the  notation  BX/  or  BIX/  where  X must 
be  between  one  and  20.  This  area  will  be 
restricted  to  arithmetic  computation. 

7.3  POOL  Instructions 

7.3.1  Alphabetical  Listing 

In  this  list,  all  POOL  instructions  are  presented 
alphabetically  with  their  group  numbers. 


Iasi  taction 

laactiaa 

2 

ADC 

A,  B,C 

A*B=C  if  A 

is  not  blank 

2 

ADD 

A,  B,C 

A*B=C 

27  i 

i 

APR 

A, B,D, C 

Store  value  at  D from 
field  C in  NIPS  record 
ID  B of  file  DDNAHE  A 

3 

BEQ 

A 

branch  if  B 

EQ 

A 

* 

22 

1 

BFN 

A,  B 

branch  to  B 
ON  field  A. 

if 

invalid 

22 

BFV 

A,B 

branch  to  B 
field  A. 

if 

valid  OH 

3 

BGE 

A 

branch  if  B 

GT 

or  EQ  A 

• 

3 

BGT 

A 

branch  if  B 

GT 

A 

i - 3 

BLE 

A 

branch  if  B 

LT 

or  EQ  A 
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££OU£  lQSt£ji£tion  reaction 


3 

BLT 

A 

branch  if  B LT  A 

3 

BNE 

A 

branch  if  B NOT  EQ  A 

3 

BNR 

A 

branch  if  new  record 

3 

BN  V 

A 

branch  if  invalid  (GEN, 

TBL,  VAL, AFT) 

3 

BPO 

A 

branch  if  pga  sw  1 is  ON 

3 

BRA 

A 

branch  unconditionally 

3 

BRO 

A 

branch  if  overflow 

9 

BSS 

A 

create  subset  for  field  A 
before  subset  or  at  end  of 
set  if  all  records  have  been 
processed. 

3 

BS2 

A 

branch  if  pgn  sw  2 is  ON 

3 

BTN 

A 

branch  if  ON  found  any  field 
invalid. 

3 

BTV 

A 

branch  if  OH  found  all  fields 
valid. 

13 

CLR 

A 

set  field  A to  blanks 

17 

COA 

A ,B 

compare  alphabetic  B to  A 

18 

CON 

A,  B 

coapare  numeric  B to  A 

20 

CVF 

A 

delete  variable  field  A in 
current  periodic  subset,  or 
delete  all  subsets  in  vari- 
able set  A. 

\ 
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<2£2££  Instruction 

4 DDE 

5 OS  B A f B 

9 DSC  A 

2 DVC  A,B,C 

2 DVD  A , B ,C 

4 END 

23  ERR  A,B 


6 GEN  Af  BfC| D 

4 HLT 

3 LNK  A 

tO  LOG  A 

1 MAC  A,B 


delete  current  NIPS  record 
and  branch  to  logic  statement 
exit . 

delete  subset  containing 
field  A.  Address  the  next 
subset  in  the  set  or  branch 
to  B if  the  last  subset  was 
deleted. 

delete  subset  containing 
field  A.  Address  the  next 
subset . 

A/B=C  if  A is  not  blank 
A/B=C 

end  of  logic  statement. 

SODA:  underscore  the  invalid 
field  A and  display  the 
literal  B. 

OM:  error  log  field  A with 
literal  B. 

call  sub/tab  B to  process 
field  A.  Store  the  result 
at  D.  Use  validity  code  C. 

establish  logic  statement 
exit 

branch  to  A.  Save  NSI  address 
for  RET. 

print  field  A on  first  printer 
(same  as  PRT) 

move  alphabetic  A to  B if  A 
is  not  blank. 
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iflglxjislion 

Function 

1 

HAL 

A.B 

aove  alphabetic  A to  B 

19 

HCS 

A.B 

aove  alphabetic  A to  minor 
control  field  B. 

14 

HCT 

A.B 

aove  alphabetic  A to  aajor 
control  field  B. 

14 

MCW 

A,  B 

execute  HCT  and  write 
iaaediate 

7 

MNC 

A.B 

aove  nuaeric  A to  B if  A is 
not  blank 

7 

MNU 

A.B 

aove  numeric  A to  B 

2 

MUC 

A.  B.C 

A*B*C  if  A is  not  blank 

2 

MUL 

A.B.C 

A*B»C 

21 

MVF 

A.B 

aove  A to  variable  field  or 
variable  set  B.  Variable 
set'  field  length  is  FFT 
definition;  transaction  field 
nay  b®  split 

21 

MVB 

A.B 

aove  A to  variable  field  or 
variable  set  B.  Variable  set 
field  length  is  transaction 
length 

4 

NCT 

no  operation 

4 

NOP 

no  operation 

25 

OVF 

A.B.C 

move  variable  field  A to  work 

area  B.  Move  anxiaua  256  bytes  per 
execution.  When  the  last  segaent  of 
the  variable  field  has  been  aoved. 
branch  to  C 
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i 


1 


i 


££OU£  laSiMSUfiD 


Function 


12  PCH  A 


punch  A (pocket  1) 


12  PC2  A 


punch  A (pocket  2) 


5 POS  A,B 

16  POV  A,B,C 

12  PRT  A 

12  PT2  A 


find  first  subset  for  field 
A.  If  none,  go  to  B 

find  first  subset  for  field 
B which  contains  value  A.  If 
none,  go  to  C 

print  field  A on  first  printer 
(same  as  LOG) . 

print  field  A on  second  printer. 


4 RET 


branch  to  instruction  following 
last  LNK. 


26  RVF  A 


11  SDT  A 


reset  OVF  segnent  pointer  for 
variable  field  or  variable 
set  A to  first  byte  in  the 
field 

store  FM  start  date/tine  in 
A.  YYDDDTTTT. 


4 

4 

4 

3 


SIE 
SIH 
SIL 
SMR  A 


set  condition  to  EQ 

set  condition  to  GT 

set  condition  to  LT 

branch  to  A when  last  RANGE 
record  has  been  processed. 


4 

SOF 

set 

overflow 

OFF 

4 

SOO 

set 

overflow 

ON 

4 

SPF 

set 

pge  sw  1 

OFF 

' 


1 
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fit  2J1£  Ial£U£tion 

24  SSS  A 

5 STP  A#B 

16  ST V A,B,C 


2 SUB  A,B,C 

2 SUB  A,B,C 

4 SVF 

4 SVO 

4 S2F 

4 S20 

6 TBL  A , B ,C , D 

8 VAL  A,  B,C 

12  MET  A 

12  HT2  A 

4 SPO 

4 SRF 

4 SBO 

i 

I 

J 

! 


store  consecutive  nunber  in 
£ield  A (all  subsets)  . 

address  next  subset  for  field 
A.  If  none,  resume  sequential 
execution  of  POOL  instructions. 

address  subset  which  follows 
subset  for  field  B which 
contains  value  A.  If  none,  go 
to  C. 


A-  B=  C 

A- B=C  if  A is  not  blank. 

) 

set  validity  sw  to  valid 
(see  SNV)  . 


set  validity  sw  to  invalid 
(see  BNV)  . 

set  pgm  sw  2 OFF 

set  pgm  sw  2 ON 

I 

lookup  value  A in  table  B 
using  condition  C.  Store 
the  function  at  D. 


call  subroutine  B to  process 
value  A using  condition 
C. 

write  A on  auxiliary  file  1 
write  A on  auxiliary  file  2. 
set  pgm  sw  1 ON 
set  new  record  sw  OFF 


set  new  record  sw  ON 
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instruction 

Punction 

12 

HT  3 A 

write  A on 

auxiliary 

file  3. 

12 

HT4  A 

write  A on 

auxiliary 

file  4. 

12 

HT5  A 

write  A on 

auxiliary 

file  5. 

4 

XNP  - 

branch  to 

exit  if  no 

exception 

processing.  If  not  the  first 
instruction  in  a RANGE  state- 
sent  it  is  a no-operation. 


I 7.3.2  Valid  Operands  Chart 

Sysbols  used  in  the  chart  have  the  following  meanings: 

TP  - transaction  field 
DP  - data  file  field 
IA  - indirect  address 
ha  - work  area 
LV  - literal  value 
SL  - statement  label 
ST  - subroutine  or  table 
VC  - code  value 

A - alphabetic 

N - numeric  t 

B - binary 
E - EBCDlC(work) 

C - coorindate 

CP  - control  field 
\ PS  - periodic  set 

GR  - group 

V - variable  field (periodic  or  variable  set) 
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SilfiJUJ.pIS.j.-Bl. 

I A WA  LV 

Pi  T 1 

SL 

r — r i 

VC 

A 

rri 

i 1 

_!s  L 

r~L~ 

"“1 

OPEBANL  - 

Quitted  groups  have 

i i 

no 

•C#  c 

>per 

and 

2 1 lx 

X X 

i 

X 

X 

X 

X 

X 
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7.3.3  Instruction  Groups 

The  POOL  instructions  are  organized  into  various  groups 
according  to  the  number  of  operands  and  operand  types 
allowed.  Therefore,  all  the  permissible  operands  are 
indicated  by  the  respective  group  of  each  instruction.  The 
following  subsection,  which  discusses  each  POOL  instruction, 
will  also  indicate  to  which  group  it  belongs. 

The  following  tables  are  organized  by  instruction 
groups.  For  each  group,  the  nuaber  of  operands,  the 
instructions  that  belong  to  the  group,  and  a list  of  the 
legal  operands  are  shown.  The  following  legend  should  be 
used  to  interpret  the  legal  operands. 


DF 

- 

Data  File 

IA 

- 

Indirect  Address 

LV 

- 

Literal  Value 

SL 

- 

Symbolic  Instruction  Label 

ST 

- 

Subroutine  or  Table 

TF 

- 

Transaction  Field 

VC 

- 

Validity  Code 

HA 

- 

Hork  Area 

Group  1 

********************************************************* 
♦Nuaber  of  Operands-2 

♦ Instructions-MAC,  HAL 

* 

♦Legal  A Operands  Legal  B Operands 

* TF,  HA  , LV  , I A , DF  WA,IA,DF 

********************************************************* 


Group  2 

********************************************************* 
♦Number  of  Operands-3 

♦Instructions- ADC, ADD,DVC,DVD,HUC,HUL,SOB,SOC 

* 

♦Legal  A Operands  Legal  B Operands 

♦ T F, W A , LV , I A , DF  TF,W A, LV, IA ,DF 

* 

♦Legal  C Operands 
♦ HA, IA, DF 
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I 

! 

' 

I 

♦ 

1 


Group  3 

********************************************************** 


*Nuaber  of  Operands-1  * 

♦Instructions-BEQ,BGE,BG?,BlE,BLT,BNE,BNF ,BT¥, BTN,  * 

* BNV, BPO , BRA , BPO, BS2 , LNK , SNF  * 

* * 

♦Legal  A Operands  ♦ 

♦ SL  ♦ 


*************************************** ******************* 


Group  4 

********************************************************** 


♦Number  of  Operands-None  * 

♦Instruct ions- DDR, END, HLT,NCT,NOP,RET,SIE,SIH,  ♦ 

♦ SIL , SOF , SOO ,S  FP, SPO ,SRF,SRO,SVF,  * 

* SV0,S2F,S20,XNP  * 


********************************************************** 


Group  5 

********************************************************** 


♦Number  of  Operands-2  ♦ 
♦Instructions-DSB, POS, STP  * 
* * 
♦Legal  A Operands  Legal  B Operands  ♦ 
♦ IA,DP  SL  ♦ 


********************************************************** 


Group  6 l 

•*•••**•* *************************************** ********** 


♦Number  of  Operands-4 
♦Imstructions-GEN, TBL 

• 

♦Legal  A Operands 

• TF,NA , LV , DP 
e 

♦Legal  C Operands 

• »C 


* 

* 

* 


Legal  B Operands  ♦ 

ST  ♦ 

* 

Legal  D Operands  ♦ 

WA ,DP  * 


******************* 
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I 
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Group  7 

********************************************************** 

•Number  of  Operands-2  * 

♦Instructions-HNC, HNO  * 

* * 

♦Legal  A Operands  Legal  B Operands  * 

* TF,HA,LV,IA,DF  TF, H A , LV , I A , DF  * 

********************************************************** 

Group  8 

********************************************************** 

♦Nuaber  of  Operands-3  * 

♦Instructions-VAL  » 

* * 

♦Legal  A Operands  Legal  B Operands  ♦ 

♦ TF,MA,LV,IA,DP  ST  ♦ 

♦ * 

♦Legal  C Operands  * 

♦ VC  ♦ 


********************************************************** 


Group  9 

********************************************************** 

♦Numoer  of  Operands-1  * 

♦Instructions-BSS, DSC  ♦ 

♦ * 

♦Legal  A Operands  ♦ 

♦ I A, DF  ♦ 

********************************************************** 

Group  10 

********************************************************** 

♦Nuaber  of  Operands  - 1 * 

♦ Instructions  - LOG  ♦ 

♦ * 

♦ Legal  A Operands  ♦ 

♦ TF,LV, EBCDIC  WA,  ALPHA  AND  DECIMAL  DF  ♦ 

********************************************************** 


J 
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Group  11 

******************  ******  ********4141  ****41  *******  ******  ****** 


♦Number  of  Operands-l  * 

♦Instr uctions-SDT  * 

* * 

♦Legal  A Operands  * 

♦ HA, IA, DF  ♦ 

******************  **************************************** 

Group  12 

********************************************************** 

♦Number  of  Operands-l  ♦ 

♦Instruct ions-PCH, PC2 , PFT, PT2, HFT , WT2 ,WT3 , ♦ 

♦ HT4,  HT5  ♦ 

♦ * 

♦Legal  A Operands  ♦ 

♦ TF, L V , EBCDIC  HA,  Alpha  and  Decinal  DF  * 

********************************************************** 

Group  13 

********************************************************** 
♦Number  of  operands-l  ♦ 

♦Instructions-CLF  * 

♦ * 

♦Legal  A Operands  ♦ 

* TF, HA , IA , DF  ♦ 

******************  **************************************** 

Group  14 

********************************************************** 
♦Number  of  Operands-2  ♦ 

♦Instr action s-HCT, HCN  ♦ 

* • 

♦Leg?l  A Operands  Legal  B Operands  * 

* TF,H  A, LV , I A, DF  IA , D F * 

********************************************************** 


Group  15  Reserved 
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Group  16 

******************************* *************************** 

♦Nuaber  of  Operands-3  * 

♦Instructions-POV, STV  * 

* * 

♦Legal  A Operands  Legal  B Operands  * 

♦ TF,WA,LV,IA,DF  I A , DF  * 

* * 

♦Legal  C Operands  ♦ 

♦ SL  ♦ 

********************************************************** 

Group  17 

********************************************************** 
♦Nuaber  of  Operands-2  * 

♦Instructions-COA  * 

♦ * 

♦Legal  A Operands  Legal  B Operands  * 

♦ TF, WA,LV , I A,DF  TF, N A,LV, IA , DF  * 

***************************************  ******************* 

Group  18 

********************************************************** 
♦Nuaber  of  Operands-2  ♦ 

♦Instructions-CON  * 

* * 

♦Legal  A Operands  Legal  B Operands  * 

* TF,«A, LV, IA,DF  TF , W A, LV , I A , DF  * 

********************************************************** 

Group  19 

********  ************************************************** 

♦Nuaber  of  Operands-2  ♦ 

♦instructions-MCS  * 

* # 

♦Legal  A Operands  Legal  B Operands  ♦ 

♦ TF,WA,LV,IA,DP  IA , DP  * 


******************  **************************************** 
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Group  20 

******************  * **************  *41*#  *-•  *********  ********** 

♦Number  of  Operands-1  * 

♦Instructions-CVF  * 

* * 

♦Legal  A Operands  ♦ 

* DF  * 

********************************************************** 

Group  21 

********************************************************** 

♦Number  of  Operands-2  * 

♦Instructions-HVF,  MVR  ♦ 

♦ * 

♦Legal  A Operands  Legal  B Operands  ♦ 

♦ TF, tf A, LV , I A, DF  (Variable  Field)  DF  ♦ 

TF  (Variable  Set)  DF  * 

********************************************************** 

Group  22 

*********************************************************** 

♦Number  of  Operands-2  ♦ 

♦ Instructions-BFV,  BFN  ♦ 

♦ * 

♦Legal  A Operands  Legal  B Operands  * 

♦ TF  SL  ♦ 

*********************************************************** 

Group  23 

*********************************************************** 

* 
* 
* 
* 
* 

********************************* ******************* ******* 


♦Nuaber  of  Operands-2 
♦Instructions-ERR 

* 

♦Legal  A Operands 
* TF 


Legal  B Operands 
L V 
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Group  24 

*************************************** ********* ********** 
•Nuaber  of  Operands  - 1 
•Instructions  - SSS 

* 

•Legal  A Operands 
* IA,DF, NUMERIC  OF  BINARY 

********************************************************** 


Group  25 

********************************************************** 


•Nuaber  of  Operands-3 
•Instruct ion s-OVF 

* 

•Legal  A Operands  Legal  B Operands 

* DF  HA 

* 

•Legal  C Operands 
* SL 

**************************************************** ****** 


1 

l 

1 


l 

* 


Group  26 


•Nuaber  of  Operands-1 
•Instructions-RVP 

* 

•Legal  A Operands 

* DF 

* 


Group  27 


•Nuaber  of  operands  - 4 
•Instruction  - APR 
* 

•Legal  A Operands 

* TF,L¥,HA 
a 

•Legal  C Operands 

* TF,L¥,HA 

* 


Legal  B Operands 
TF,L¥#HA 

Legal  D Operands 
HA 


********************************************************** 
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7.4  POOL  Instructions 

There  are  84  POOL  instructions  available,  each  of  which 
can  be  used  to  build  the  updating  logic  statements  for  FM. 
These  instructions  can  be  divided  into  five  basic  types 
according  to  the  function  they  perform.  These  are: 

a.  Environment  establishing  instructions  which 
allow  the  user  to  selectively  handle  the 
periodic  set  fields  of  the  data  base. 

b.  Data  handling  instructions  which  allow  the 
user  to  perform  processing  against  the  fields 
of  the  data  base  such  as  moving,  arithmetic 
operations,  and  transformation. 

c.  Control  instructions  used  to  control  the 

sequence  of  instruction  execution. 

d.  Display  instructions  which  allow  the  user  to 
specify  certain  output  functions. 

e.  Validity  test  instructions  and  error  logging 
instructions  used  with  OH  and  SODA. 

Each  of  the  84  POOL  instructions  (within  its  basic  type) 
is  described  below. 

7.4.1  Environment  Handling  Instructions 
Position  to  First  Subset  of  Periodic  Set  (Group  5) 

POS  A, B 

This  instruction  causes  the  first  subset  of  the 
periodic  set  containing  field  A to  be  made  active; 
i.e.,  positioned  so  that  processing  can  be 
performed  on  the  data  contained  in  the  first 
subset.  If  there  are  no  subsets  of  the  set  in  the 
current  data  record,  the  instruction  with  tag  B 
will  be  executed  next. 

Step  to  Next  Subset  of  Periodic  Set  (Group  5) 

STP  A, B 
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This  instruction  causes  the  next  subset  after  the 
current  active  subset  of  the  periodic  set 
containing  field  A to  becoie  active.  If  there  is 
no  other  subset  to  be  made  active,  the  activity  is, 
in  effect,  placed  after  the  last  subset  and 
sequential  execution  of  the  POOL  instructions 
resumes.  If  the  instruction  is  successful  the  next 
subset  is  made  active  and  the  instruction  with  tag 
B is  executed. 


Position  on  Value  (Group  16) 

POV  A, B, C 

This  instruction  causes  the  activity  for  a periodic 
set  to  be  placed  at  the  first  subset  with  the  field 
specified  by  operand  B containing  the  data  value 
specified  by  operand  A.  If  no  subsets  of  the  set 
meet  the  requirement,  the  instruction  with  tag  C 
will  be  executed  next. 

Step  to  Value  (Group  16) 


STV  A, B ,C 

This  instruction  causes  the  next  subset,  after  the 
current  subset  that  contains  the  data  value 
specified  by  operand  A in  the  field  specified  by 
operand  B,  to  be  made  active.  If  no  subsets  of  the 
set  meet  the  requirements,  the  instruction  with  tag 
C is  executed  next. 

Delete  Subset  of  Periodic  Set  and  Branch  (Group  5) 

DSB  A, B 

This  instruction  causes  the  currently  active  subset 
of  the  periodic  set  containing  field  A to  be 
deleted  from  the  current  data  record.  If  the 
deleted  subset  was  the  last  of  the  periodic  set, 
the  subset  activity  is  placed  after  the  last  one, 
and  a transfer  to  the  instruction  with  tag  B is 
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aade.  Otherwise,  the  next  subset  is  aade  active, 
and  sequential  operation  continues. 

Delete  Subset  of  Periodic  Set  and  Continue  (Group  9) 

DSC  A 

This  instruction  causes  the  active  subset  of  the 
periodic  set  containing  field  A to  be  deleted  froa 
the  current  data  record.  If  there  is  a subset  of 

the  saae  set  following  the  deleted  subset,  it  is  - 

activated.  If  not,  the  activity  is  placed  after  1 

the  last  one.  In  either  case,  sequential  operation 

continues.  1 

Build  Subset  of  Periodic  Set  (Group  9)  \ 

BSS  A \ 

) 

This  instruction  causes  a subset  of  the  periodic 
set  containing  field  A to  be  built  . and  placed  in 
the  current  data  record.  The  active  subset  of  the 
periodic  set  and  any  that  follow  are  aoved  down  in 

the  data  record,  and  the  newly  generated  subset  is  ,| 

placed  in  the  position  formerly  occupied  by  the 

last  active  subset.  If  the  activity  was  placed 

after  the  last  subset  of  the  periodic  set  by  some 

previous  instruction,  the  new  subset  is  placed 

after  the  last  one.  In  either  case,  the  newly  i 

created  subset  becomes  active  and  is  ready  for 
processing  by  other  instructions. 

Delete  Current  Data  Record  (Group  4) 

DDR 

This  instruction  notifies  PH  that  the  current  data 
record  is  to  be  deleted;  i.e.,  not  to  be  included 
in  the  output  data  file.  After  execution  of  this 
instruction,  all  processing  is  terminated  for  the  < 

update  statement. 

Sequence  Subsets  (Group  24) 


SSS  A 
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This  instruction  places  sequence  numbers  in  field 
A of  the  periodic  containing  field  A.  The  sequence 
numbers  will  always  begin  with  one  and  will  always 
be  incremented  by  one  for  each  subset.  This 
instruction  may  not  be  used  to  nodify  the  contents 
of  the  system  generated  PSSQ  fields. 


7.4.2  Data  Handling  Instructions 
Auxiliary  File  Reference  (Group  27) 

AFR  A,B,C,D 

This  instruction  allows  the  user  to  move  the 
contents  of  field  C of  the  data  record  with 
major  record  identification  B of  the  ISAM  or 
VSAM  file  with  DDNAME  A into  the  EBCDIC  work 
area  D.  The  auxiliary  file  must  be  a NIPS 
data  file  of  ISAM  or  VSAM  organization,  but 
must  not  be  the  primary  data  file.  Field  C 
must  be  an  alpha  field  or  group,  a numeric 
field  or  group,  a decimal  field  or  group, 
variable  field,  or  a coordinate  field  within 
the  fixed  set.  Binary  and  coordinate  data  is 
converted  to  EBCDIC  before  being  placed  into 
the  work  area  D.  If  the  data  from  the  field 
C has  an  output  length  greater  than  the 
specified  work  area  length  truncation  occurs 
from  the  right.  If  field  C is  shorter  than 
the  work  area,  the  data  is  left  justified  and 
padded  on  the  right  with  blanks.  If  any  error 
occurs  that  prohibits  the  return  of  data  to 
the  work  area  (i.e.,  no  DD  card  with  DDNAME  A, 
no  existing  major  record  identification  B,  I/O 
error) , an  error  is  logged  fully  describing 
the  problem,  and  the  validity  indicator  is  set 
to  invalid.  Only  if  the  referenced  data  is 
successfully  returned  to  work  area  D is  the 
validity  indicator  set  to  valid.  AFR  operates 
in  a read  only  mode;  no  data  can  be  entered 
into  the  auxiliary  file  with  this  instruction. 
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Move  Alphabetic  Field  to  Field  (Group  1) 

HAL  A , B 

This  instruction  moves  the  content  of  field  A to 
field  B.  The  content  of  field  A is  treated  as 
alphabetic  information.  If  the  field  to  be  moved 
is  shorter  than  field  B,  blanks  are  appended  on  the 
right.  If  the  field  to  be  moved  is  longer  than 
field  B,  the  resultant  content  of  field  B is 
truncated  from  the  right. 

Note:  The  * MAL*  instruction  is  based  on  a 369  ALC  move 

instruction  which  moves  left  to  right  through  each 
field  a byte  at  a time.  Therefore,  caution  must  be 
used  whenever  fields  overlap  (e.  g. , MAL 
W10/12,  Hi  1/1  3)  . 

Move  Numeric  Field  to  Field  (Group  7) 

MNU  A , B 

This  instruction  causes  the  content  of  field  B to 
be  set  to  the  content  of  field  A.  The  content  of 
field  A is  assumed  to  be  a numeric  guantity.  If 
the  field  to  be  moved  is  shorter  than  field  B, 
necessary  zeros  are  appended  on  the  left.  If  the 
field  to  be  moved  is  longer,  the  resultant  content 
of  field  B will  be  truncated  from  the  left. 
Numeric  transaction  data  nay  be  signed  or  unsigned. 
Signed  transaction  data  will  have  the  sign  set  in 
the  low-order  byte  during  processing;  if  unsigned, 
the  data  is  considered  positive.  Transaction  data 
nay  be  signed  in  two  ways:  (1)  the  sign  nay  be 
placed  in  the  low  order  zone;  e.g. , -2  would  be 

punched  as  a K,  ♦ 1 would  be  punched  as  an  A,  etc.; 
(2)  a ♦ sign  or  - sign  may  immediately  precede  the 
first  digit  of  the  data  (although  a ♦ sign  will  in 
effect  be  ignored) . 

Note:  The  'MNU'  instruction,  when  moving  data  from  a 

decimal  area  to  a decimal  area,  uses  a 360  ALC  move 
instruction  which  moves  left  to  right  through  each 
field  a byte  at  a time.  Therefore,  caution  must  be 
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used  whenever  fields  overlap  (e.g.,  MNU 
N10/12,N11/1  3)  . 

Move  Conditional  Alphabetic  Field  tc  Field  (Group  1) 

MAC  A,B 

This  instruction  is  executed  exactly  as  HAL  except 

that  if  the  field  to  be  moved  is  blank,  no  action 

is  taken;  i.e.,  field  B is  left  undisturbed. 

Move  Conditional  Numeric  Field  to  Field  (Group  7) 

HNC  A, B 

This  instruction  is  executed  exactly  as  MNU  except 
that  if  the  content  of  field  A is  blank,  no  action 
is  taken;  i.e.,  all  of  field  B is  left  undisturbed. 

All  of  the  following  arithmetic  operations  use  three 
operands.  The  user  specifies  in  the  A and  B operands  the 

fields  with  which  the  arithmetic  operation  is  to  be 

performed.  These  two  fields  are  not  disturbed  by  the 
operation. 

The  C operands  specify  the  field  into  which  the  result 
of  the  operation  is  to  be  stored. 

If  he  desires,  the  user  may  specify  the  same  field  for 
all  three  operands  or  for  any  two  operands.  For  instance, 
he  nay  add  A to  B and  store  the  result  in  A. 

Add  Field  A to  Field  B,  Store  in  Field  C (Group  2) 

ADD  A, B, C 

This  instruction  algebraically  adds  the  content  of 
field  A to  the  content  of  field  B and  stores  the 
result  in  field  C.  The  resultant  sum  is  moved 
numerically  to  field  C,  and  the  sum  is  truncated  or 
extended  by  zero  characters  on  the  left  as 
appropriate.  If  the  resultant  sun  is  truncated, 
the  overflow  indicator  is  turned  on. 
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Add  Conditional  Field  A to  Field  B,  Store  in  Field  C (Group 
2) 

ADC  A,B,C 

This  instruction  is  identical  in  execution  to  ADD 
except  that  if  the  content  of  field  A is  blank,  no 
action  is  taken. 

Multiply  Field  A by  Field  B,  Store  in  Field  C (Group  2) 

MUL  A , B ,C 

This  instruction  causes  the  content  of  field  A to 
be  algebraically  multiplied  by  the  content  of  field 
B and  the  result  to  be  stored  in  field  C.  As  with 
ADD  the  result  is  stored  numerically  in  field  C, 
and  the  overflow  indicator  is  set  as  appropriate. 


Multiply  Conditional  Field  A by  Pield  B,  Store  in  Field  C 
(Group  2) 

MUC  A,  B , C 

This  instruction  is  identical  in  execution  to  MUL 
except  that  execution  does  not  take  place  if  the 
content  of  field  A is  blank. 

Divide  Field  B into  Field  A,  Store  in  Field  C (Group  2) 

DVD  A,B,C 

This  instruction  causes  the  content  of  field  A to 
be  divided  by  the  content  of  field  B and  the  result 
to  be  stored  in  field  c.  Results  are  moved  to 
field  C numerically  from  right  to  left,  and  zeros 
are  truncated  or  added  on  the  left  as  required. 


The  overflow 

Remainders  are 

indicator 

lost. 

is 
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This  instruction  is  executed  exactly  as  DVD  except 
that  execution  does  not  take  place  if  the  content 
of  field  A is  blank. 

Subtract  Field  B from  Field  A,  store  in  Field  C (Group  2) 

SUE  A,B,C 

This  instruction  algebraically  subtracts  the 
content  of  field  B from  the  content  of  field  A and 
stores  the  result  in  field  C.  The  result  is  stored 
numerically  from  right  to  left,  and  zeros  are 
truncated  or  added  to  the  left  as  required.  If 
field  C will  not  contain  the  result,  the  overflow 
indicator  is  turned  on.  Otherwise,  it  is  turned 
off. 

Subtract  Conditional  Field  B from  Field  A,  Store  in  Field  C 

(Group  2) 


SUC  A,  B, C 

This  instruction  is  identical  in  execution  to 
SUB  except  that  if  the  content  of  field  A is  blank, 
the  content  of  field  C remains  unchanged. 

Clear  Variable  Data  Field  (Group  20) 

CVF  A 

This  instruction  causes  the  variable  data  field  of 
the  current  data  file  record  to  be  cleared.  The 
length  of  the  variable  data  field  is  effectively 
set  to  zero. 

Move  to  Secondary  Control  Field  (Group  19) 

MCS  A , B 

This  instruction  moves  the  contents  of  field  A to 
field  B.  The  instruction  is  treated  as  an 
HAL  instruction.  This  is  the  only  instruction  that 
may  be  used  to  alter  the  contents  of  a subset 
control  field. 
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This  instruction  is  executed  exactly  as  DVD  except 
that  execution  does  not  take  place  if  the  content 
of  field  A is  blank. 

Subtract  Pield  B from  Pield  A,  Store  in  Pield  C (Group  2) 

SUE  A,B,C 

This  instruction  algebraically  subtracts  the 
content  of  field  B fro*  the  content  of  field  A and 
stores  the  result  in  field  C.  The  result  is  stored 
numerically  from  right  to  left,  and  zeros  are 
truncated  or  added  to  the  left  as  required.  If 
field  C will  not  contain  the  result,  the  overflow 
indicator  is  turned  on.  Otherwise,  it  is  turned 
off. 

Subtract  Conditional  Field  B from  Pield  A,  Store  in  Field  C 

(Group  2) 


SUC  A, B,C 

This  instruction  is  identical  in  execution  to 
SUB  except  that  if  the  content  of  field  A is  blank, 
the  content  of  field  C remains  unchanged. 

Clear  Variable  Data  Field  (Group  20) 

CVF  A 

This  instruction  causes  the  variable  data  field  of 
the  current  data  file  record  to  be  cleared.  The 
length  of  the  variable  data  field  is  effectively 
set  to  zero. 

Move  to  Secondary  Control  Pield  (Group  19) 

MCS  A, B 

This  instruction  moves  the  contents  of  field  A to 
field  B.  The  instruction  is  treated  as  an 
HAL  instruction.  This  is  the  only  instruction  that 
nay  be  used  to  alter  the  contents  of  a subset 
control  field. 
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Move  Control  Field  (Group  14) 

MCT  A , B 

This  instruction  eoves  the  contents  of  field  A to 
field  B.  If  truncation  is  required,  the 

instruction  is  treated  as  the  eove  alphabetic 
instruction  (HAL) . MCT  and  MCW  are  the  only 
instructions  which  can  alter  the  contents  of  the 
record  control  field.  Subsequent  transactions  that 
■atch  the  old  record  key  are  still  applied  to  this 
record. 

Move  Control  Pield  and  Write  the  Data  Record  (Group  14) 

MCW  A , B 

This  instruction  functions  in  the  saae  Banner  as 
MCT  except  that  the  data  record  is  output  upon 
coapletion  of  the  execution  of  the  logic  stateaent 
in  which  an  execution  of  an  MCW  instruction  has 
occurred.  A subsequent  transaction  that  Batches 
the  old  record  key  will  cause  a new  record  with  the 
old  key  to  be  generated. 

If  a NIPS  ISAM  file  is  being  updated  and  the  step 
abnoraally  terminates,  all  records  whose  control 
field  was  changed  up  to  that  point  have  been 
deleted  froa  the  file.  The  new  records  nay  not 
have  been  written  onto  the  file,  depending  on  where 
the  step  terainaticn  occurred. 
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Look  Up  Tabular  Function  Value  (Group  6) 

TBL  A, B,C, D 

This  instruction  causes  the  contents  of  the 
transaction  input  field  A to  be  used  as  an  argument 
to  the  tabular  function  B (code  conversion  table) 
to  produce  a function  value  which  is  stored  in 

field  D.  The  result  of  the  tabular  function  is 
assuwed  to  be  alphabetic  and  is  left- justified  in 
field  D.  The  function  value  is  truncated  or  padded 
with  blank  characters  on  the  low-order  end  as 
required.  If  the  input  field  A does  not  cowpare 
with  entries  of  the  tabular  function,  the 
disposition  of  the  transaction  input  record  is 

determined  by  C.  The  legal  values  of  C are  A,  I, 

or  R.  The  transaction  input  record  disposition  is 
as  described  for  the  C operand  of  VAL.  The 

validity  indicator  is  set  to  valid  or  invalid,  as 
appropriate,  by  this  instruction.  Note  that  inputs 
to  tables  and  subroutines  nay  be  data  base  fields, 
work  areas,  or  transaction  fields. 

Generate  Value  frow  Argument  Field  (Group  6) 

GEN  A , B,C, D 

The  execution  of  this  instruction  is  identical  to 
that  of  TBL  except  that  B is  the  nane  of  a non- 
tabular  function. 

Store  Date-Tine  in  Field  (Group  11) 

SDT  A 

This  instruction  stores  the  current  Date-Tine  Group 
(DTG)  in  field  A.  The  DTG  reflects  the  tine  that 
this  FH  run  started.  The  fornat  of  the  value 
stored  is  XXTTYZZZZ  in  which 

XX  * Year  (00-99) 

YYY  * Date  (000-366) 

ZZZZ  * 24  hour  tine  (0000-2400)  to  the  hundredths 
of  hours 
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The  9-character  DTG  field  is  stored  alphabetically 
in  field  A.  The  DTG  is  truncated  or  padded  on  the 
right  as  required  (see  HAL). 

Move/Add  Variable  Field  to  Variable  Field  (Group  21) 

MVF  A,B 

This  instruction  updates  variable  fields  in 
periodic  sets  and  adds  data  to  the  end  of  variable 
sets.  Hhen  used  to  update  periodic  sets,  the 
contents  of  field  B will  be  replaced  by  the 
contents  of  field  A.  Hhen  used  to  add  to  variable 
sets,  the  transaction  input  data  (field  A)  is 
appended  to  the  variable  set  identified  by  field  B. 
The  input  data  is  packed  into  fixed-length  subset 
records;  new  subset  records  are  created  whenever 
necessary. 

Hove  to  Variable  Set/Field  (Group  21) 

NVR  A, B 

This  instruction  appends  the  contents  of  the 
transaction  input  field  A to  the  contents  of  the 
variable  data  field  specified  by  the  B field.  If 
the  original  length  of  the  variable  data  set  is  N, 
and  the  length  of  field  A is  H,  the  resultant 
length  of  the  data  set  will  be  N+M.  If  the  B field 
is  a variable  field  in  the  periodic  set,  the 
previous  contents  of  the  field  will  be  replaced  by 
the  contents  of  field  A.  The  difference  between 
MVF  and  NVR  is  this:  the  length  of  each  subset 
field  in  a variable  set  is  obtained  fros  the  FFT  by 
MVF;  the  lengths  of  all  subset  records  in  the  set 
are  the  sase  (except  for  the  last,  which  say  be 
shorter).  NVR  uses  the  input  transaction  length 
(field  A)  as  the  output  length;  subset  records  say 
vary  in  length.  This  sethod  reduces  the 
probability  of  splitting  words  between  subset 
records.  Only  words  which  are  split  between  input 
transactions  will  be  split  between  subset  records. 
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Output  Variable  Field  to  Work  Area  (Group  25) 

OVF  A , B,  C 

This  instruction  will  move  a portion  of  the 
variable  field  A to  the  defined  work  area  specified 
by  the  B field.  The  variable  field  A nay  be  stored 
in  a periodic  set  or  a variable  set.  The  B field 
also  determines  the  length  of  the  move.  Up  to  256 
characters  can  he  moved  at  a single  execution.  A 
pointer  is  then  set  to  the  remaining  unmoved 
portion  of  the  variable  A field  so  that  the  next 
execution  of  this  instruction  will  move  another 
portion  of  the  variable  field  data.  If  the 
remaining  portion  of  the  field  is  shorter  than  the 
work  area  receiving  the  data,  the  receiving  field 
is  first  cleared  and  then  the  data  is  moved.  The 
pointer  is  then  reset  to  the  beginning  of  the 
variable  field,  and  a branch  is  taken  to  the  label 
specified  in  the  C operand.  If  the  length  of  the 
variable  field  is  zero,  the  work  area  is  cleared  to 
blanks  and  a branch  is  taken  to  the  C operand 
label. 

Reset  Variable  Field  Pointer  to  Beginning  of  the  Variable 
Field  (Group  26) 


RVF  A 

This  instruction  will  reset  the  pointer  which  is 
used  in  the  OVF  instruction  back  to  the  beginning 
of  the  var'tble  field.  It  may  be  used  only  when  an 
OVF  instr  action  with  the  same  A operand  appears 
within  the  logic  statement. 

Clear  Field  (Group  13) 


CLR  A 

This  instruction  sets  field  A to  blanks.  Field  A 
cannot  be  a record  control  ID. 

Note:  The  processing  operators  discussed  above,  with  the 
exception  of  BVF,  MVR,  CVF,  OVF,  and  FVP  apply  both  to 
nonperiodic  and  periodic  fields.  Reference  nay  be  made  to 
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nonperiodic  fields  at  any  point  in  a logic  statement,  but 
reference  to  fields  of  a periodic  set  nay  occur  only  when  a 
subset  of  that  periodic  set  is  currectly  active.  Periodic 
sets  are  independent  of  each  other,  and  subsets  of  two  or 
■ore  periodic  sets  may  be  active  simultaneously . Only  one 
subset  of  a given  periodic  set  aay  be  active  at  any  given 
tiae. 


7.4.3  Control  Instructions 

Compare  Field  to  Field  Alphabetic  (Group  17) 

CO  A A,  B 

This  instruction  compares  the  content  of  field  A to 
the  content  of  field  B.  Both  operand  fields  are 
assumed  to  be  alphabetic,  and  comparison  takes 
place  from  left  to  right.  If  the  B field  is 
shorter  than  the  A field,  the  comparison  will  be 
made  as  if  the  B field  were  padded  on  the  right 
with  blanks.  If  the  A field  is  shorter  than  the  B 
field,  only  the  common  portion  of  the  two  fields  is 
compared.  The  compare  indicator  is  set  as  follows: 

Condition  Compare  Indicator  Setting 


A equal  to  B EQUAL 

B greater  than  A HIGH 

B less  than  A LOW 


Compare  Field  to  Field  Homeric  (Group  18) 

CON  A ,B 

This  instruction  causes  the  content  of  field  B to 
be  compared  to  the  content  of  field  A.  Both 
operand  fields  are  assumed  to  be  numeric  and 
comparison  is  algebraic.  The  relative  lengths  of 
the  operand  fields  are  not  a criterion  for 
meaningful  comparison.  Both  operand  fields  are 
assumed  to  be  assigned  whole  numbers.  The  sign  of 
each  operand  field  is  indicated  by  the  setting  of 
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the  zone  bits  of  the  low-order  character.  The 
coapare  indicator  is  set  as  follows: 


Condition  Coapare  Indicator  Setting 


A equal  to  B EQUAL 

B greater  than  A HIGH 

B less  than  A LOW 


Check  Field  for  Validity  (Group  8) 


VAL  A,  B,  C, 


This  instruction  causes  the  contents  of  field  A to 
be  processed  by  the  subroutine  B to  determine  if 
the  content  Beets  specifications  contained  in 
subroutine  B.  Field  C specifies  whether  to  log  an 
error  if  the  content  of  field  A is  deterained  to  be 
invalid.  The  codes  for  field  C are: 


Value  of  C Disposition  or  Action 


A or  R 
I 


Appropriate  error  aessage  is  logged  on 
history  file  and  invalid  data  is  skipped 
No  error  aessages  printed  - invalid  data 
is  skipped 


The  validity  indicator  is  set  to  valid  or  invalid, 
as  appropriate,  by  this  instruction. 


Branch  Unconditionally  (Group  3) 


BRA  A 


This  instruction  causes  an  unconditional  branch  to 
the  instruction  with  tag  A. 

Branch  Unconditionally  and  Link  (Group  3) 

INK  A 


9 3 
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This  instruction  causes  an  unconditional  branch  to 
tag  A.  The  location  of  the  instruction  following 
the  LNK  instruction  is  saved  for  use  with  the  RET 
instruction. 

Return  Branch  (Group  4) 


RET 

This  instruction  causes  an  unconditional  branch  to 
the  instruction  following  an  LNK  instruction.  An 
LNK  instruction  must  have  been  executed  prior  to 
the  execution  of  the  RET  instruction.  These  two 
instructions  can  be  used  to  provide  closed 
subroutines  in  logic  statements.  Only  one  level  of 
closed  subroutines  nay  be  used  at  any  given  time. 

The  following  instructions  test  the  compare  indicator. 
The  indicator  is  reset  to  indicate  the  result  each  time  a 
compare  instruction  is  executed. 

Branch  if  not  Equal  (Group  3) 

BNE  A 

This  instruction  causes  a transfer  to  the 

instruction  with  tag  A if  the  compare  indicator  is 
either  high  or  low. 

Branch  if  Greater  Than  or  Egual  (Group  3) 

BGE  A 

This  instruction  causes  a transfer  to  the 

instruction  with  tag  A if  the  compare  indicator  is 
set  either  high  or  equal. 

Branch  if  Less  Than  (Group  3) 

BLT  A 

This  instruction  causes  a transfer  to  the 

instruction  with  tag  A if  the  coapare  indicator  is 
low. 
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Branch  if  Equal  (Group  3) 

BBQ  A 

This  instruction  causes  a transfer  to  the 

instruction  with  tag  A if  the  coapare  indicator  is 
equal. 

Branch  if  Less  Than  or  Equal  (Group  3) 

BLE  A 

This  instruction  causes  a transfer  to  the 

instruction  with  tag  A if  the  coapare  indicator  is 
set  equal  or  low. 

Branch  if  Greater  Than  (Group  3) 

BGT  A 

This  instruction  causes  a transfer  to  the 

instruction  with  tag  A if  the  compare  indicator  is 
set  high. 

Set  Indicator  Low  (Group  4) 

STL 

This  instruction  sets  the  indicator  low. 

Set  Indicator  Equal  (Group  4) 

SIE 

This  instruction  sets  the  indicator  equal. 

Set  Indicator  High  (Group  4) 

SIH 

This  instruction  sets  the  indicator  high. 

The  following  instructions  are  concerned  with  the 
validity  indicator.  Execution  of  the  TBL # GEN , APR,  and  VAL 
instructions  sets  this  indicator  to  valid  (off)  or  not  valid 
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(on).  It  is  initialized  to  valid  before  the  execution  of 
each  logic  statement.  During  OH  POOL  logic  statement 
execution,  the  switch  is  set  to  invalid  by  OH  if  a picture 
error  occurs. 

Branch  if  Not  Valid  (Group  3) 

BNV  A 

This  instruction  causes  a transfer  to  the 
instruction  with  tag  A if  the  validity  indicator  is 
set  to  not  valid. 

Set  Validity  Switch  On  (Group  4) 

SVO 

This  instruction  sets  the  validity  switch  on,  (not 
valid) . 

Set  Validity  Switch  Off  (Group  «) 

SVF 

This  instruction  causes  the  validity  switch  to  be 
turned  off  (valid)  . 

The  following  instructions  are  concerned  with  the 
overflow  switch.  This  switch  is  set  on  any  time  an 
arithmetic  operation  results  in  an  overflow  condition.  It 
is  turned  off  by  any  arithmetic  operation  that  does  not 
result  in  an  overflow  condition.  It  is  initialized  to  off 
before  execution  of  the  logic  statement  begins. 

Branch  if  Overflow  (Group  3) 

BPO  A 

This  instruction  causes  a transfer  to  the 
instruction  with  the  tag  A if  the  overflow 
indicator  is  set  to  on. 

Set  Overflow  Switch  off  (Group  4) 

SOP 
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This  instruction  causes  the  overflow  switch  to  be 
turned  off. 

Set  overflow  Switch  On  (Group  4) 

SOO 

This  instruction  sets  the  overflow  switch  on. 

The  following  instructions  are  concerned  with  the  new 
record  switch  which  is  turned  on  any  tine  a new  record  is 
generated.  New  records  are  generated  when  an  equal 
conparison  of  the  input  transaction  and  data  record  control 
fields  cannot  be  made.  The  new  record  switch  is  turned  on 
prior  to  the  execution  of  the  first  logic  statenent  used  to 
process  a new  record.  It  will  be  turned  off  prior  to 
executing  any  subsequent  logic  statements  that  are  used  to 
process  the  sane  record. 

Branch  if  New  Record  (Group  3) 

BNR  A 

This  instruction  causes  a transfer  to  the 
instruction  with  tag  A if  the  new  record  switch  is 
on . 

Set  New  Record  Switch  On  (Group  4) 

SRO 

This  instruction  sets  the  new  record  switch  on. 

Set  New  Record  Switch  Off  (Group  4) 

SRP 

This  instruction  causes  the  new  record  switch  to  be 
turned  off. 

The  following  instructions  deal  with  the  two  program 
switches.  These  switches  are  provided  to  assist  the  user  in 
controlling  his  logic.  The  user  nay  turn  then  on  and  off  as 
required.  They  are  initialized  to  off  prior  to  each 
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execution  of  a logic  statement.  Note:  Each  valid 
transaction  will  execute  a logic  stateaent. 

Set  Prograa  Switch  On  (Group  4) 

SPO 

This  instruction  sets  the  prograa  switch  on. 

Set  Prograa  Switch  No.  2 On  (Group  4) 

S20 

This  instruction  sets  prograa  switch  No.  2 on. 

Set  Prograa  Switch  Off  (Group  4) 

SPF 

This  instruction  causes  the  prograa  switch  to  be 
turned  off. 

Set  Prograa  Switch  No.  2 Off  (Group  4) 

S2F 

This  instruction  causes  program  switch  No.  2 to  be 
turned  off. 

Branch  if  Prograa  Switch  On  (Group  3) 

EPO  A 

This  instruction  causes  a transfer  to  the 
instruction  with  tag  A if  the  prograa  switch  is  on. 

Branch  if  Prograa  Switch  No.  2 is  On  (Group  3) 

BS2  A 

This  instruction  causes  a transfer  to  the 
instruction  with  tag  A if  prograa  switch  No.  2 is 
on. 


. 


— 
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The  following  Miscellaneous  control  instructions  are 
also  available  to  the  user. 

Branch  on  Suaaary  (Group  3) 

SHR  A 

This  instruction  causes  a transfer  to  the 
instruction  with  tag  A when  the  last  record  has 
been  processed.  This  instruction  is  valid  only  for 
range  statenents. 

Halt  (Group  4) 


HLT 

This  instruction  specifies  that  no  further 
processing  is  to  be  perforned  against  the  current 
data  record. 

No  Operation  (Group  4) 

NOP 

This  instruction  performs  no  operation. 

End  of  Logic  (Group  4) 

END 

This  instruction  signifies  to  the  language  compiler 
that  the  end  of  the  logic  statement  has  been 
reached. 

NOP  The  Diagnostic  Instruction  Counter  (Group  4) 

NCT 

This  instruction  is  a carryover  from  1410  NIPS  and 
has  been  included  in  NIPS  360  FFS  to  maintain 
coapatability.  The  NCT  instruction  has  no 
operational  function  in  NIPS  360. 
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Exit  if  no  Prior  Processing  on  Data  Record  (Group  4) 

XNP 

This  instruction  is  used  to  provide  the  Exception 
Range  capability.  It  is  effective  only  when  it 
appears  as  the  first  instruction  in  a RANGE 
statement.  If  it  appears  anywhere  else,  it 
functions  as  an  NOP.  Mhen  this  instruction  appears 
as  the  first  instruction  in  a RANGE  statement,  it 
causes  an  immediate  exit  fro*  the  RANGE  statement 
if  the  data  record  being  processed  has  not  been 
subjected  to  Exception  updating  during  the  run. 

7.4.4  Display  Instructions 

For  all  display  instructions,  the  length  of  field  A 
cannot  exceed  994  bytes.  NIPS  adds  six  overhead  bytes  to 
the  data  specified  by  field  A and  the  DCB  LPECL  is  1000. 
Violation  of  this  limit  will  result  in  a System  001  ABEND 
(I/O  ERROR,  RECORD  TOO  LONG). 

Log  Comment  (Group  10) 


LOG  A 


This  instruction  causes  the  contents  of  field  A to 
be  written  on  the  printer  in  batch  mode  and  on  the 
display  screen  in  TP  mode. 

Note:  Carriage  control  nay  be  specified  by  coding  an 
optional  B operand.  This  operand,  if  coded,  must  be 
preceded  by  a comma  and  enclosed  in  quotes.  Valid  B 
operands  are: 


0 (zero)  - space  two  lines 

- (minus)  - space  three  lines 

1 (one)  - eject  (In  TP  mode,  this 

character  will  cause 
the  screen  to  blank) 


Print  Comment  (Group  12) 


PRT  A 


J 
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This  instruction  is  the  sane  as  log.  See  above 
note. 

Print  Coanent  (Group  12) 


PT2  A 

This  instruction  is  the  sane  as  LOG  and  PFT  except 
it  writes  operand  A data  on  the  printer  in  batch 
node  and  on  an  OMQ  display  device  in  TP  node.  See 
above  note. 

Write  on  AOF  (Group  12) 

NRT  A 

This  instruction  causes  the  contents  of  field  A to 
be  written  on  the  auxiliary  output  file. 

Hrite  on  Second  AOP  (Group  12) 

«?2  A 

This  instruction  causes  the  contents  of  field  A to 
be  written  on  the  second  auxiliary  output  file. 

Write  on  Third  AOF  (Group  12) 

HT3  A 

This  instruction  writes  the  contents  of  field  A on 
the  third  auxiliary  output  file. 

Nrite  on  Fourth  AOF  (Group  12) 

WT4  A 

This  instruction  writes  the  contents  of  field  A on 
the  fourth  auxiliary  output  file. 

Hrite  on  Fifth  AOF  (Group  12) 

NTS  A 
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This  instruction  writes  the  contents  of  field  A on 
the  fifth  auxiliary  output  file. 

Punch  Output  (Group  12) 


PCH  A 

This  instruction  causes  the  contents  of  field  A to 
be  punched  in  punch  pocket  one. 

Punch  Output  (Group  12) 


PC2  A 

This  instruction  punches  the  contents  of  field  A in 
punch  pocket  two. 


7.4.5  ordinary  Maintenance  Validity  Test  Instructions 

The  following  group  of  instructions  nay  be  used  to  test 
the  results  of  the  Ordinary  Maintenance  validation 
functions.  Instructions  are  provided  to  allow  testing  of 
the  validity  of  a given  field,  or  the  entire  transaction. 
These  instructions  are  as  follows: 

Branch  on  Transaction  Field  Valid  (Group  22) 

BPV  A, B 

Exaaple  - BFV  $TR ANS,OK 

This  instruction  branches  to  location  •B1  if  the 
contents  of  transaction  field  A passed  the  Ordinary 
Maintenance  edit  tests.  The  transaction  field  eust  be 
designated  by  its  assigned  mnenonic. 

Branch  on  Transaction  Field  Not  Valid  (Group  22) 

BFN  A , B 

Exanple  - BFN  STR ANS , BAD 

This  instruction  branches  to  location  *B*  if  the 
contents  of  transaction  field  'A'  failed  any  of  the  Ordinary 
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M Maintenance  error  tests.  The  transaction  field  nast  be 

designated  by  its  assigned  TD  nnenonic. 

Branch  on  Transaction  Valid  (Group  3) 

BTV  A 

This  instruction  branches  to  location  'A'  if  all  of  the 
transaction  data  passed  on  specified  Ordinary  Maintenance 
validity  tests. 

Branch  on  Transaction  Not  Valid  (Group  3) 

BTN  A 

This  instruction  branches  to  location  *A'  if  any 
transaction  fields  failed  the  specified  validity  tests. 

J 

7.4.6  Transaction  Error  Log  Instruction  (SODA  and  OH) 

Log  Erroneous  Transaction  Data  (Group  23) 

ERR  A , B 

Exanple  - ERR  $?RANS,'THIS  IS  BAD  DATA* 

This  instruction  is  provided  to  assist  the  terminal 
operator  in  correcting  erroneous  transaction  data  when  using 
the  on-line  update  capability.  Source  Data  Autonation 
(SODA)  . 

When  this  instruction  is  executed  during  a SODA  run,  it 
causes  the  displayed  transaction  field  'A*  to  be  underscored 
with  a key  to  the  nessage  provided  as  the  literal  in  field 
'B'.  (See  the  Terainal  Processing  (TP)  conponent  volune  of 
the  NIPS  369  FFS  Users  Manual.) 

when  this  instruction  is  executed  during  a batch  PH  run, 
it  causes  the  nessage  tc  be  printed  on  the  Ordinary 
Maintenance  error  log  (see  section  6.2).  In  a conbined 
Ordinary  Maintenance/POOL  logic  statenent.,  this  instruction 
nay  be  used  to  replace  or  supplenent  the  standard  ON  error 
aessages. 
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7.5  Logic  Statement  Examples 

The  following  examples  illustrate  the  setup  of  the  PM 
run  deck  for  updating  the  Logic  Stateaent  Library,  and  the 
use  of  soie  of  the  POOL  language  instructions.  Sections 
9.5.3  through  9.5.8  provide  equivalent  NPL  logic  stateaents 
for  the  POOL  language  stateaents  of  sections  7.5.3  through 
7.5.8.  All  of  the  exaaples  pertain  to  the  TEST36J7  file. 
Por  a description  of  this  file,  see  the  Introduction  to  Pile 
Concepts  voluae  of  the  NIPS  360  FPS  Users  Manual. 

All  of  the  saaple  logic  stateaents,  with  the  exception 
of  the  Range  stateaent,  perform  updates  with  transactions 
froa  the  report  'RPT360*.  The  different  transaction  formats 
within  this  report  are  identified  by  the  letters  'A'  through 
•G*  in  column  1 of  the  transaction. 

Sections  7.5.1  through  7.5.8  illustrate  the  free~foraat 
FMS  control  card,  library  action  cards,  and  TD  cards. 

Coaaents  cards  are  shown  in  each  of  the  logic  stateaents 
and  explain  the  functions  of  the  stateaents. 

Section  8.1  provides  an  equivalent  Ordinary  Maintenance 
TD  of  the  POOL  statement  in  section  7.5.6.  Section  8.2 
shows  a coabination  OM/POOL  logic  statement. 


7.5.1 


PMS  Control  Card 


The  following  PMS  control  card  would  be  used  to  execute 
the  'LIB*  node  of  PM,  to  perform  updates  for  the  logic 
stateaent  library  for  the  TEST360  file: 

(PM S/LI B , TEST 3 60 


7. 5.1.1 


LIMIT  Control  Card 


The  following  card  would  be  used  when  the  user  wanted  to 
liait  a range  to  all  the  records  whose  control  field,  LCTRL, 
was  equal  to  'AAA' . 

(LIMIT, LCTRL, EQ, AAA  or 
(LIMIT, LCTRL, BT , AAA/AAA 
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*! 


i 


> 


If  all  records  not  equal  to  'AAA'  were  desired,  then  the 
control  card  would  be: 

ALIN IT, LCTFL,NOT, EQ, AAA 
7,5.2  Library  Action  Card  to  Add  a Report 

The  following  card  would  be  used  to  add  the  report 
'HPrShU'  to  the  Logic  Statement  Library.  The  transaction  ID 
field,  for  transactions  within  this  report,  is  located  in 
coluen  1. 

SAB, BPT360, 1 

This  card  could  also  have  been  punched  as  follows: 

SAB, BPT 360, 1-1 

However,  since  the  transaction  ID  field  is  only  one  byte 
long,  the  is  not  required. 


7.5.3  Logic  Statement  Setup 

The  following  exaeple  illustrates  the  organization  of 
the  library  action  card,  the  TD  cards,  the  language 
identifier  card,  and  the  POOL  instruction  cards  for  an 
Exception  logic  statement.  The  sample  statement  performs 
updates  with  the  'A*  transaction  format  of  the  report 
• RPT360* . 

The  first  card  for  the  statement  is  the  library  action 
card.  This  card  specifies  that  the  statement  is  to  be 
permanently  added  to  the  library.  It  also  specifies  that 
the  statement  will  perform  updates  with  the  'A'  transaction 
of  report  ' HPT360',  and  that  the  fixed  data  in  that 
transaction  format  is  80  bytes  long.  The  transaction  does 
not  contain  any  variable  data. 

The  TD  cards  follow  the  library  action  card.  The  first 
field  in  each  of  these  cards  is  used  to  assign  mnemonics  to 
the  transaction  data  fields. 
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The  second  and  third  fields  specify  the  high-order 
position  and  the  low-order  position  of  the  transaction 
fields. 

The  fourth  field  is  used  to  specify  that  a transaction 
field  is  a major  or  user  control  field.  In  the  example, 
SR EC  ID  is  a najor  transaction  control  field,  and  it 
corresponds  to  the  data  record  control  group,  'Uic*.  JSORT 
is  a user  transaction  control  field.  It  is  not  used  in 
■atching  a transaction  record  to  a data  record,  but  is 
associated  with  the  record  control  field  to  control  the  file 
processing  sequence. 

The  fifth  field  in  the  TD  card  indicates  the  type  of 
data  that  the  transaction  fields  will  contain.  The  'A' 
transaction  contains  alphabetic  (A)  data  and  zoned  decimal 
(D)  data  only.  Insertion  of  this  field  is  optional,  with 
the  default  option  being  'D'. 

The  card  following  the  TD  card  is  the  language 
identifier  card,  and  contains  the  word  'POOL'  in  colunns  16- 
19. 


Conaent  cards,  describing  the  logic  statement 's 
function,  follow  the  language  identifier  card.  The  comment 
cards  are  identified  by  an  asterisk  (*)  in  column  6. 

The  logic  statement  first  tests  the  new  record  switch  by 
using  the  BN R instruction.  A new  record  will  be  generated 
by  FH  when  no  data  record  can  be  found  with  a UIC  group  that 
matches  the  contents  the  JFECID  transaction  field,  in  an  'A' 
transaction.  When  this  occurs,  the  instructions  at  NEVREC 
will  be  executed.  These  instructions  format  a print  line  in 
the  EBCDIC  work  area  and  print  the  line.  At  the  completion 
of  this  function,  the  instruction  sequence  at  HOVE  is 
executed.  This  sequence  of  instructions  moves  the  data  from 
the  transaction  field:  to  the  data  record  fields,  using  the 
HAL,  MAC,  anjl  HNC  instructions.  The  HAL  and  HAC 
instructions  are  used  to  move  the  alphabetic  data  to  the 
file  record,  and  the  HNC  instruction  is  used  to  move  the 
numeric  data  to  the  file  record. 

When  the  HAC  instruction  at  HOVE  is  executed,  no  data 
transfer  will  take  place  if  the  content  of  the  transaction 
field  SHOHE  is  blank.  Hhen  the  HNC  instruction  is  executed. 
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no  data  transfer  will  take  place  if  the  content  of  the 
transaction  field  $PEPS  is  blank. 

The  instructions  that  move  the  transaction  data  to  the 
coordinate  fields  DAPT1-4  will  automatically  convert  the 
data  to  internal  coordinate  fornat. 

At  the  completion  of  execution  of  the  data  aove 
instructions,  an  SDT  instruction  is  executed.  This 
instruction  stores  the  date/tiae  of  the  update  in  the  data 
field  LAUD. 

A HLT  instruction  is  executed  next.  This  instruction 
causes  an  exit  froa  the  logic  statement. 


FILE  MAINTENANCE  (FN) 


SASP,RPT367,A,87 
$RECID,2,7,Cl, A 
SSORT,8,8,C2, A 
SHONE, 17,17, , A 
SATTACH ,12, 12, , A 
SF  (IT  UR  E, 13, 13,, A 
SPOINT,13, 25,  ,D 
SAREA1,27,37,,A 
SABEA2 ,38, 48,, A 
SABEA3,49, 59, , A 
SAREA4,67,79, , A 
SPEHS, 73,87, ,D 
POOL 

* THIS  LOGIC  STATEMENT  HILL  UPDATE  THE  LOCATION  AND  DEPLOYMENT 

* AREA  OF  THE  SPECIFIED  UNIT.  IF  A NEW  RECORD  IS  GENERATED,  A 

* MESSAGE  MILL  BE  PRINTED  AND  THE  TRANSACTION  FIELDS  BILL  BE 

* MOVED  TO  THE  DATA  FIELDS. 

* 

BNR  NEWREC 

MOVE  MAC  SHONE, HONE 

HAL  SATTACH, ATACH 
MAL  SFUTURE, PUTU 
MAL  SPOINT, POINT 


J 
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1 

PILE  MAINTENANCE 

(PH) 

1 

] 

| 

i 

MAI. 

$APEAl,D  APT1 

HAL 

SAREA2.DAPT2 

HAL 

$ ARE A3 ,DAPT3 

J 

i 

HAL 

$A  REA4#D APT4 

MNC 

f PERS,PERS 

j 

1 

SDT 

LAUD 

} 

j 

HLT 

J 

NEW  NEC  MAL 

•NEN  RECORD  GENERATED.  ID  IS  - ',Wl/3 ft 

i 

1 

MAL 

$RECID,W 31/36 

PRT 

Hl/36 

1 

i 

i 

BRA 

HOPE 

HLT 

'] 

END 

» 

j 

1 

• 

1 " 

J ' ^ 

1 
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7.5.4  Use  of  Data  Conversion  Subroutines 

The  following  logic  statement  is  used  with  *B' 
transactions.  These  transactions  contain  only  a aajor 
control  field  in  positions  2 through  7. 

This  logic  statement  verifies  that  the  CNTRT  and  ACTIV 
fields,  in  selected  records,  contain  valid  data. 

If  a new  record  is  generated  by  a 'B'  transaction,  the 
DDR  instruction  at  'DELETE'  is  executed  to  delete  the 
record.  Otherwise,  positions  1 to  44  of  the  work  area  are 
cleared  to  blanks,  and  the  data  record's  UIC  field  is  moved 
to  the  work  area.  Then  *he  data  in  CNTRY  is  converted  by 
the  subroutine  CTRYS,  and  the  result  is  stored  in  the  work 
area.  If  the  data  is  invalid,  asterisks  are  noved  to  the 
work  area  by  the  instructions  at  ' ERR1' . Next  the  data  in 
ACTIV  is  converted  by  the  subroutine  ACTVS,  and  the  result 
is  stored  in  the  work  area.  If  the  data  is  invalid, 
asterisks  are  moved  to  the  work  area  by  the  instructions  at 
'ERR2*.  Then  the  contents  of  the  work  area  is  printed,  and 
the  logic  statement  exits. 

Note:  Execution  of  the  TBL  instructions  does  not  alter  the 

contents  of  the  fields  CNTRY  or  ACTIV. 
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$ASP,RPT360,B,80 
SRECID,2, 7, Cl, A 
POOL 

* THIS  LOGIC  STATEMENT  HILL  EXTRACT  THE  COUNTRY  CODE  AND 

* THE  ACTIVITY  CODE  POR  SPECIFIED  UNITS. 

BNR  DELETE 

CLR  Wl/44 

MAL  UIC , Wi/6 

TBL  CNTR Y,CTRYS, I, Hid/ 2 4 

BN V ERR1 

ACT V TBL  ACTIV,  ACTVS,  I,H30'/44 

BN  V ERR  2 

PRT  PRT  Hl/44 

HLT 

ERFI  MAL  ***************** # W10/24 

BRA  ACT V 

ERR 2 HAL  i ***************1 f *3^/44 

BRA  PRT 
DELETE  DDR 
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7.5.5  Periodic  Set  Processing 

The  following  examples  illustrate  two  methods  for 
updating  periodic  subsets.  Example  1 uses  an  Exception 
update  statement  to  perform  the  updating  of  the  record.  The 
library  action  card  will  add  statement  'D'  of  report  type 
' R PT36IJ'  permanently  to  the  Logic  Statement  Library.  The  TD 
cards  assign  mnemonics  to  the  transaction  fields,  with 
transaction  field  SRECID  containing  the  major  control  field 
of  the  record  to  be  processed. 

The  'POV'  instruction  will  cause  the  subset  of  periodic 
set  one  to  be  searched  for  the  data  field  ' HECLQ  * oeing 
equal  to  the  transaction  field  ' SHEQPT' . If  it  is  not 
found,  a branch  is  taken  to  • NEW* . If  it  is  found  the 
indicated  processing  will  be  done. 

At  'NEW,  a new  subset  will  be  built  for  Periodic  Set  1. 
The  subset  control  field  will  be  set  by  the  'HCS* 
instruction,  and  the  remaining  transaction  fields  will  be 
set  in  the  specified  data  fields.  A message  is  printed  to 
indicate  a new  subset  was  created  and  the  transaction  field 
SMEQPT  is  printed. 

Example  2 uses  direct  subset  update  capability.  The 
library  action  card  is  the  same.  The  TD  card  for  the 
transaction  field  • SHEQPT*  is  different  in  that  the  control 
parameters  on  the  TD  card  indicate  that  the  field  is  to  be 
used  as  a subset  control  field.  It  also  carries  a data 
record  subset  control  field  parameter  nane  'HECLQ'  which  is 
defined  as  a subset  control  group  in  the  FFT . If  no  subset 
exists  with  a total  record  control  group  (major  control 
field,  set  number,  and  subset  control  group)  equal  to  the 
update  record  control  group  (SRECID,  set  number,  SHEQPT)  a 
new  subset  is  generated  by  ?M  and  the  total  record  control 
group  is  set  in  the  new  subset  and  the  new  record  indicator 
is  set  on.  If  the  subset  exists,  the  subset  is  made  active. 


The  first  instruction  tests  the  new  record  indicator. 
If  it  is  on,  a branch  is  taken  to  'NEW.  If  it  is  not  on, 
the  processing  is  performed. 

At  'NEW',  the  field  is  updated,  and  the  messages  are 
printed. 
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SlAflPLg.l 
SASP,  RPT360 , D,  80 
$RECID,2,7,C1,A 
$MEQPT,10r,22,  , A 
$NOEQPT,25,27,,D 
SAODCOOE ,29, 29,, A 
POOL 

* THIS  LOGIC  STATEMENT  HILL  SEARCH  FOR  THE  SUBSET 

* CONTAINING  THE  EQUIPMENT  TYPE  AND  ADD  OR  SUBTRACT 

* THE  NUMBER  OF  ITEMS  AS  SPECIFIED  BY  THE  ADD  CODE.  IF 

* THE  SUBSET  DOES  NOT  EXIST,  A NEW  SUBSET  HILL  BE  BUILT 

* AND  THE  FIELDS  HILL  BE  UPDATED. 

POV  JMEQPT, M FCLQ, NEW 
COA  JADDCODE , * A* 

BEQ  ADD 

SUB  ME PSD, $NOEQPT, HE PSD 
HLT 

ADD  ADD  NEPSD, JNOEQPT , HE PSD 
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NEW  BSS  NECLQ 

HCS  SNEQPT , H ECLQ 

HNU  SNOEQPT, MEPSD 

PRT  'NEW  SUBSET  CREATED* 

END 

EXAMPLE_2 
SASP,RPT360,D,80 
SB EC ID, 2, 7, Cl, A 
SMEQPT,10T,22,  , A,S,MECLQ 
SNOEQPT, 25,27, ,D 
SADDCODE, 29, 29,, A 
POOL 

* THIS  STATEMENT  HILL  PEPPORM  THE  SAME  FUNCTION,  USING 

* THE  DIRECT  SUBSET  UPDATE  CAPABILITY.  IF  THE  SUBSET 

* DOES  NOT  EXIST  A NEW  SUBSET  HILL  BE  GENERATED  AND  THE 

* SUBSET  CONTROL  FIELD  HILL  BE  AUTOMATICALLY  SET  BY  FH. 

* 

BNR  NEH 

COA  SADDCODE, 'A* 

BEQ  ADD 

SUB  MEPSD, SNOEQPT, MEPSD 
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ADO 

ADD 

HEPSD,  JNOEQPT, MEPSD 

HLT 

NEW 

HN(J 

SNOEQPT, HEPSD 

PRT 

•NEW  SUBSET  CREATED* 

PILE  MAINTENANCE  (PH) 


7.5.6  Test  for  Numeric  Data 

The  following  logic  statement  illustrates  a simple 
method  of  determining  if  a transaction  field  contains 
invalid  numeric  data  (assuming  valid  data  is  a nonzero  value 
within  the  range  $2, 147,483,647) . This  method  is  especially 
applicable  when  it  is  not  known  in  exactly  what  position  of 
the  field  the  data  begins  and/or  ends  (e. g.,  when  leading 
zeros  are  not  required  or  the  right- justi fication  capability 
of  the  system  is  being  used).  It  is  also  applicable  when 
some  of  the  data  may  be  signed  and  some  nay  be  unsigned. 

(The  PICTURE  instruction  can  be  used  in  Ordinary  Maintenance 
or  NPL  to  perform  the  editing  function  when  the  type  of  data 
in  each  column  is  known  - see  sections  8.1,  8.2,  and  9.4.6.) 

When  the  logic  statement  is  entered,  a CON  instruction 
is  executed  to  compare  the  operand  value  with  zero.  This 
will  cause  the  transaction  data  to  be  edited  (see  section 
4.2).  If  the  transaction  field  contains  a valid  nonzero  ^ 

numeric  value,  the  comparison  will  be  n£t  equal;  if  the 
transaction  field  contains  invalid  data,  the  comparison  will 
be  equal. 


( 
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SASP,RPT360,E,80 
JTRANS, 1,80 
SR ECID,2,7,C1 
SPERSONL,  10, 15 
SREADAVG, 20, 22 
SRITNM,25,27 

POOL 

* THIS  LOGIC  STATEMENT  WILL  UPDATE  NUMERIC  FIELDS  IN 

* THE  FIXED  SET.  THE  INPUT  TRANSACTION  FIELDS  CONTAIN 

* DECIMAL  DATA.  THE  DECIMAL  DATA  IS  EDITED  TO  DETERMINE 

* IF  IT  CONTAINS  ANY  INVALID  CHARACTERS.  IF  AN  ERROR 

* IS  DETECTED,  AN  ERROR  MESSAGE  WILL  BE  PRINTED  ON  THE 


* 

AUXILIARY 

OUTPUT  PRINTER 

AND  THE 

ERRONEOUS 

TRANSACTION 

* 

WILL  BE  PRINTED. 

CON 

0, SPERS  CNL 

TEST  IF 

SPERSONL 

NUMERIC 

BEQ 

ERR1 

BRANCH 

IF  INVALID 

DATA 

MNU 

SPERSONL,PERS 

CHK2 

CON 

SREADAVG, 0 

BEQ 

ERR2 

MNU 

$ READAVG,READAVG 

CHK3 

CON 

0, RITNM 

FILE  MAINTENANCE  (FH) 

MNU  SRITNR, FITNH 
HLT 

ERR  1 PRT  'THE  JPERSONL  FIELD  CONTAINS  INVALID' 

PRT  • NUMERIC  DATA  OR  A VALUE  OF  ZERO' 

PRT  $TR ANS 
BRA  CHK2 

ERR2  PRT  'THE  SR EADAVG  FIELD  CONTAINS  INVALID' 

PRT  'NUMERIC  DATA  OR  A VALUE  OF  ZERO' 

PRT  STRANS 
BPA  CHK  3 

ERR 3 PRT  'THE  SPITNH  FIELD  CONTAINS  INVALID' 

PRT  'NUMERIC  DATA  OR  A VALUE  OF  ZERO' 

PRT  STRANS 

HLT 

END 


PILE  MAINTENANCE  (FM) 


7.5.7  Production  of  Summary  Information 

The  following  logic  statement  is  a Range  statement  that 
functions  without  transaction  data.  Note  that  the  library 
action  code  for  this  statement  contains  only  the  function 
code  ' SAST*,  and  that  there  are  no  TDD  cards  for  this 
statement.  This  type  of  statement  must  be  compiled  on-line 
each  time  it  is  used. 

This  statement  uses  the  SMR  instruction  to  determine 
when  line  processing  is  completed.  When  processing  is  not 
complete,  the  three  instructions  that  follow  the  SHR 
instruction  are  executed,  and  a logic  statement  exit  is 
taken.  These  instructions  accumulate  information  in  the 
first  three  words  of  the  binary  work  area. 

When  processing  is  completed,  the  SHP  instruction  causes 
a branch  to  the  instruction  sequence  at  'LAST*,  where  final 
processing  and  printing  of  the  accumulated  data  takes  place.  J 

Note  that  when  the  data  is  moved  from  the  binary  work  area 
to  the  EBCDIC  work  area,  it  is  automatically  converted  to 
zoned  decimal  format. 
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SAST 

POOL 

* RANGE  STATEMENT  TO  CALCULATE  TOTAL  NUMBER  OF  UNITS 

* IN  THE  DATA  FILE,  TOTAL  PERSONNEL  STRENGTH,  AVERAGE 

* OF  TOTAL  READINESS  AVERAGE  OF  ALL  UNITS 

* THIS  INFORMATION  MILL  BE  PRINTED  ON  THE  AUXILIARY 

i 

1 

* OUTPUT  FILE 

* 

J 

SMR  LAST  1 

ADD  BI/,1, Bl/ 

) 

ADD  PERS,B2/,B2/  \ 

ADD  READAVG,B3/,B3/ 

HLT 

LAST  MAL  'TOTAL  NUMBER  OF  UNITS- ', Wl/23 

MNU  BL/, W24/29 

PRT  • • PRINT  BLANK  LINES 

PRT  ' • 

PRT  HI/29 

HAL  'TOTAL  PERSONNEL  STRENGTH  OF  ALL  UNITS-' , Hl/39 
MNU  B2/,HU0/49 
PRT  • • 

• * J 

PRT  H1/U9 
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BAL  'AVERAGE  OP  TOTAL  READINESS  AVERAGE-' , Wl/35 
DVD  B3/# Bl/, M36/37 
PRT  • • 

PRT  HI/37 

HLT 

END 


FILE  MAINTENANCE  (FM) 


7.5.8  Variable  Field  and  Set  Processing 

The  following  two  logic  statements  illustrate  the  use  of 
the  MVF  instruction. 

Exaaple  1 loves  information  from  a variable  transaction 
field,  $VAF , to  the  variable  field  COMMENT.  Existing 
information  in  COMMENT  will  be  destroyed.  When  the  data 
transfer  takes  place,  the  data  is  truncated,  so  that  any 
trailing  blanks  in  the  variable  transaction  field  are  not 
moved. 

Example  2 appends  information  to  the  variable  set  REPER. 
Since  the  information  to  be  transferred  is  in  a fixed  length 
transaction  field,  no  truncation  takes  place. 

Example  3 outputs  variable  field  (REMARK)  data.  When  a 
matching  subset  is  found,  the  data  is  moved  to  the  work  area 
in  50  character  increments,  and  printed. 
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EXAMPLE  1 

AASP,RPT360, F, 10,11 
AH EC ID, 2, 7, Cl, A 
AVAR, 11 

POOL 

* 

* THIS  LOGIC  STATEMENT  REPLACES  THE  INFORMATION  IN  THE 

* VARIABLE  FIELD  COMMENT  WITH  THE  INFORMATION  IN  THE 

* VARIABLE  LENGTH  TRANSACTION  FIELD  AVAR. 

* 

MVF  AVAR, COMMENT 

HLT 

END 

£2&tlPLE_2 

AASP,RPT36p,G,8(» 

ARECID,2,7,C1,A 
A V AR,31,8(T,,  A 

POOL 

* 

* THIS  LOGIC  STATEMENT  APPENDS  THE  INFORMATION  lit  THE 

* TRANSACTION  FIELD  AVAR  TO  THE  INFORMATION  IN  THE 

* VARIABLE  SET  REFER  . 

* 
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MVR  $V  AR , REPER 

HLT 

END 

EIAHPLE  3 
SASP,RPT360,I,80 
$R EC  ID, 2, 7, Cl, A 

POOL 

* 

* THIS  LOGIC  STATEMENT  HILL  SEARCH  THROUGH  THE  VARIABLE 

* PIELDS  (REMARK)  OF  THE  PERIODIC  SUBSETS  CONTAINING 

* THE  FIELD  MEQPT  FOR  A COMMENT  BEGINNING  WITH  THE 

* VALUE  01HAY71.  H HEN  FOUND,  THIS  VARIABLE  FIELD 

* HILL  THEN  BE  PRINTED  50  CHARACTERS  PER  LINE. 


POS 

MEQPT, NONE 

NEXT 

OVF 

REMARK, Hl/7, COMP 

COMP 

CO  A 

'01HAY71 ' , Hl/7 

BEQ 

RESET 

RVF 

REMARK 

STEP 

STP 

MEQPT, NEXT 

PRT 

•NO  HATCH  POUND' 

HLT 
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NONE 

PRT 

•NO  SUBSETS  FOUND 

HLT 

RESET 

R VP 

REMARK 

PUT 

OVF 

REMARK  # H 1/50; LAST 

PRT 

Hi/50 

BRA 

PUT 

LAST 

PRT 

HI/50 

HLT 

END 

i 


FILE  MAINTENANCE  (FM) 


7.6  Sunaary  of  POOL  Instructions 

Data  Handling  Instructions 


Instruction 

Operation 

MAL 

A,B 

Move  Alphabetic 

MNU 

A , B 

Hove  Nuneric 

MAC 

A,  B 

Move  Alphabetic  Conditional 

MNC 

A , B 

Move  Nuaeric  Conditional 

ADD 

A,B,C 

Addit ion 

ADC 

A » B#  C 

Add  Conditional 

MUL 

A,  B,  C 

Multiplication 

HUC 

A , B , C 

Multiply  Conditional 

DVD 

A » B , C 

Division 

DVC 

A,B,C 

Divide  Conditional 

SUB 

A,B,C 

Subtraction 

sue 

A , B,C 

Subtract  Conditional 

CVF 

A 

Clear  Variable  Data  Field 

HCT 

A,  B 

Move  To  Record  ID 

MCS 

A,  B 

Move  To  Secondary  Control  Field 

new 

A , B 

Hove  To  Record  ID  And  Write  Record 

VAL 

A,  B , C 

Validity  Check 

TBL 

A,B,C,D 

Table  Lookup  Routine 

GEN 

A , B , C , D 

Subroutine  Processing 

CO  A 

A,  B 

Coapare  Alphabetic 

CON 

A,  B 

Coapare  Nuaeric 

SOT 

A 

Store  Date-Tiae  Group 

HVF 

A,  B 

Hove  To  Variable  Set/Field 

MVR 

A,  B 

Hove  To  Variable  Set/Field  (Input  Length). 

OVF 

ABC 

Output  Variable  Field 

BVF 

A 

Reset  Variable  Field  Pointer 

CLR 

A 

Clear  Field 

Control  Instructions 

Instruction 

i 

Operation 

BRA 

A 

Unconditional  Branch 

LNK 

A 

Branch  And  Link 

RET 

Return  Branch 

BLT 

A 

Branch  If  Less  Than 

BEQ 

A 

Branch  If  Egual 

BLE 

A 

Branch  If  Less  Than  Or  Equal 

BGT 

A 

Branch  If  Greater  Than 
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| 

Branch  If  Not  Equal 
Branch  If  Greater  Than  Or  Equal 
Halt  Statement  Execution 
No  Operation 

Exit  No  Prior  Processinq 
Branch  On  Summary 
Branch  If  New  Record 
Branch  If  Switch  2 Is  On 
Branch  If  Overflow 
Branch  If  Invalid 
Branch  If  Program  Switch  On 
Set  Overflow  Switch  Off 
Set  Validity  Switch  Off 
Set  Program  Switch  Off 
Set  New  Record  Switch  Off 
Set  Switch  2 Off 
Set  Overflow  Switch  On 
Set  Validity  Switch  On 

Set  Program  Switch  On  ^ 

Set  Switch  2 On 
Set  New  Record  Switch  On 
Set  Indicator  Low 
Set  Indicator  Equal 
Set  Indicator  High 
NOP  Instruction  Counter 
End  Update  Statement 

Environment  Handling  Instructions 


Instruction  Operation 


POS  A,B 
STP  A, a 
POV  A,  B,  C 
ST V A,B,C 
DSB  A , B 
DSC  A 
BSS  A 
SSS  A 
DDR 


Activate  Pirst  Subset 

Step  Activity  To  Next  Subset 

Position  On  Value 

Step  To  Value 

Delete  Subset  And  Branch 

Delete  Subset  And  Continue 

Built  Subset 

Sequence  Subsets 

Delete  Data  Record 
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Display  Instructions 


Instruction 

Operation 

LOG 

A 

Print 

On 

History  File 

PUT 

A 

Print 

On 

History  Pile 

PT2 

A 

Print 

On 

History  File 

HRT 

A 

write 

On 

Auxiliary  File 

NT2 

A 

Write 

On 

2nd  Auxiliary 

File 

WT3 

A 

Write 

On 

3rd  Auxiliary 

File 

NT  4 

A 

Write 

On 

4th  Auxiliary 

File 

NT5 

A 

write 

On 

5th  Auxiliary 

File 

PCH 

A 

Punch 

Contents  Of  A Into  Punch 

Pocket 

PC  2 

A 

Punch 

Contents  Of  A Into  Punch 

Pocket 

1 

2 


Instructions  Used  With  OM  and  SODA 


IHSl£!Lcti2&  Oration 


BFV 

A#B 

BFN 

A , B 

BTV 

A 

BTN 

A 

ERR 

A,  B 

Branch  On  Transaction  Field  Valid 

Branch  On  Transaction  Field  Not  Valid 

Branch  On  Transaction  Valid 

Branch  Transaction  Not  Valid 
Log  Erroneous  Transaction  Data 
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Section  8 


ORDINARY  MAINTENANCE  (OH)  EXAMPLES 


Use  of  Ordinary  Maintenance  TD  Cards 


The  following  logic  sta 
Ordinary  Maintenance  lang 
of  editing  for  nonnumeric 
character  in  each  column 
additional  PICTURES  for  val 
flexibility,  as  needed.) 
similar  to  that  performed  b 
section  7.5.6.  It  uses 
numeric  data  in  the  transac 
correct  moves  it  to  the 
logged  on  the  Ordinary  Main 


tement,  written  entirely  in  the 
uage,  illustrates  a simple  method 
characters  when  the  type  of 
is  known.  (The  utilization  of 
ues  to  be  edited  gives  greater 
The  editing  function  performed  is 
y the  POOL  logic  statement  in 
the  PICTURE  parameter  to  test  for 
tion  fields,  and  if  the  data  is 
data  file.  Nonnumeric  data  is 
tenance  error  log. 


The  logic  statement  also  checks  the  first  byte  of  the 
transaction  record  ID  field  for  a legal  service  code,  using 
the  VALUE  parameter.  If  the  first  byte  is  in  error,  the 
transaction  is  deleted. 

$ASP,RPT360,F,8H 

FIELD  RECID  2 7 A CONTROL  1 VALUE  N***** 

ERROR  T 

FIELD  PERS  19  15  D PICTURE  NNNNNV  ERROR  D GEN 

FIELD  READAVG  29  22  D PICTURE  NNN  ERROR  D GEN 

FIELD  RITNH  25  27  D PICTURE  NNN  ERROR  D GEN 


8.2  Use  of  Ordinary  Maintenance  TD  Cards  and 
POOL  Instructions 

The  following  logic  statement  performs  the  same  function 
as  the  one  in  section  8.1,  except  that  automatic  logging  on 
the  Ordinary  Maintenance  log  is  suppressed.  Invalid  record 
control  fields  are  printed  on  the  OM  error  log  by  use  of  the 
ERR  instruction.  Logging  of  other  errors  is  performed  by 
the  POOL  statements  on  the  normal  printer  auxiliary  output. 
The  BTV  instruction  is  used  to  exit  from  the  POOL  logic  when 
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no  errors  were  found,  and  the  BFN  instructions  are  used  to 
test  for  invalid  fields. 


SASP, RPT360, E, 80 

FIELD  RECID  2 7 A CONTROL  1 VALUE  »**♦** 

N***  **  ERROR  DS 

FIELD  PERS  10  15  D PICTURE  NNNNNN  ERROR  DS  GEN 
FIELD  READAVG  20  22  D PICTURE  NNN  ERROR  DS  GEN 
FIELD  RITNM  25  27  D PICTURE  NNN  ERROR  DS  GEN 


POOL 

BTV 

EXIT 

BFN 

SR ECID, IDERR 

PRT 

Tl/80 

BFN 

SPERS, ERR1 

CHK2 

BFN 

$R  EADA VG , ERR2 

CHK3 

BFN 

SRITNM , ERR3 

EXIT 

HLT 

ERR1 

PRT 

•THE  PERSONNEL  FIELD  CONTAINS  NON-NUMERIC  DATA' 

BRA 

CHK2 

ERR2 

PRT 

•THE  READAVG  PIELD  CONTAINS  NON-NUMERIC  DATA' 

BRA 

CHK3 

ERR3 

PRT 

•THE  RITNM  PIELD  CONTAINS  NON-NUMERIC  DATA* 

BRA 

EXIT 

IDERR 

ERR 

SRECID, 'INVALID  SERVICE  CODE' 

DDR 

END 

J 
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Section  9 


NEW  FILE  MAINTENANCE  LANGUAGE  (NFL) 


NFL  is  a high-level  or  procedural  PH  language  which 
provides  the  user  with  a language  which  is  easy  to  learn  and 
simple  to  use,  yet  which  is  powerful  and  flexible  enough  to 
efficiently  accomplish  a wide  range  of  FH  functions. 

The  NFL  section  of  the  FM  component  accepts,  as  input, 
statements  written  in  an  English-like  language  describing 
the  conditions  and  actions  which  are  to  be  applied  against 
a NIPS  data  file  for  a specified  set  of  update  transactions. 
The  language  is  interpreted  and  processed  (compiled)  , 
resulting  in  an  executable  logic  statement.  Error 
conditions  are  detected,  and  diagnostics  which  will  aid  the 
user  in  correcting  the  logic  statement  are  printed. 

Before  reading  this  section,  review  sections  2 through 
6 of  this  manual. 


9.1  NFL  Statement  Composition 

NFL  statements  are  free-format.  Words  are  separated  by 
blanks,  commas,  or  periods.  Multiple  statements  can  be 
punched  on  a single  card  or  a statement  may  be  spread  over 
more  than  one  card.  Card  columns  72-80  must  not  be 
utilized.  Words,  including  literals,  nay  not  be  split  over 
two  cards.  Statements  are  composed  of  statement 
identifiers,  keywords,  noise  words,  labels,  and  operands. 
Periods  nay  be  used  freely  for  readability.  They  have  no 
effect  on  the  language  processor  in  this  component. 
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9,1.1  Statement  Identifiers 


There  are  a limited  number  of  statement  identifiers  in 
NFL  which  identify  a condition,  an  action,  or  a point  of 
control.  Though  the  number  of  statements  is  limited,  a 
number  of  functions  are  implied  simply  by  the  structure  of 
the  statements.  The  following  lists  of  identifiers  have 
been  grouped  by  category. 

Action  Condition/Logic  Control  Point 
Identifiers  Identifiers Identifiers 


MOVE 

ATTACH 

COMPUTE 

BUILD 

POSITION 

LOCATE 

STEP 

PHINT 

PUNCH 

UR  ITS 

DISPLAY 

DELETE 

DEFINE 

TURN 

GO 

RETURN 


IF 

AND 

OR 


ELSE 

CONTINUE 

PROCEDURE 

END 

NOTE 

NFL 

NFL 


Example  - 


£F  condition  AND  condition 

location,  PRIN1  data  CONTINUE 

i&VB 

from 

location 

to 

In  the  preceding  example,  IF, 

AND, 

MOVE, 

PRINT, 

and 

CONTINUE  are  statement  identifiers.  The  IF  identifies  a new 
condition  to  follow.  The  AND  identifies  a condition  to 
follow  and  denotes  that  it  is  a continuation  of  a "string" 
of  conditions  (see  section  9.3.1).  The  MOVE  and  PRINT 
identifiers  identify  actions  to  be  performed  if  the 
preceding  conditions  are  true.  CONTINUE  identifies  the 
point  to  continue  processing  regardless  of  whether  the 
preceding  conditions  were  net. 
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9.1.2  Keywords 

Keywords  differ  froa  statement  identifiers  in  that  they 
are  eabedded  in  the  statenent  and  identify  either  a 
secondary  action,  a specific  action  froa  a group  of  possible 
actions,  or  succeeding  operands.  The  following  list  of 
keywords  are  used  in  NPL.  Examples  can  be  found  in  the 
section  discussing  statement  descriptions. 


NOT 

BT 

BET0EEN 

EQ 

EQUAL 

EQUALS 

NE 

LT 

LESS 

GT 

GBEATER 

LE 

TAB 

TABLE 

PIC 

PICTURE 

SUB 

SUBROUTINE 

BIT 

ON 

OFF 


Used  to  negate  a condition 
Identifies  a between  condition 


Identifies  an  egual  condition 

Identifies  a not  egual  condition 
Identifies  a less  than  condition 

Identifies  a greater  than  condition 

Identifies  a less  than  or  equal  condition 

Identifies  a validation  table  condition  or 
conversion  of  data 

Identifies  a picture  condition 


Identifies  a data  conversion  operation 


Identifies  a bit  condition 
Identifies  an  on  (true)  condition 
Identifies  an  off  (false)  condition 
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NEW  RECORD 

JOB  COMPLETE 
JOB  COMPLETED 

OVERFLOW 

KSUford 

♦ 

/ 

* 

ON  (following 

EXIT 

BECORD 

FIELD 

SET 

SUBSET 

OVER 

PAST 

BEYOND 

NEXT 

FIRST 


Identifies  a new  record  condition 
Identifies  a run  complete  condition 

Identifies  an  overflow  condition 
Usage 
Add  operation 
Subtract  operation 
Divide  operation 
Multiply  operation 

Denotes  equivalency  in  compute  statement 

PRINT,  PUNCH,  WRITE,  DISPLAY)  signifies  that 
a device  is  being  specified 

Identifies  the  next  operand  as  an  exit  label 
Identifies  the  object  of  the  action  as  a record 

Identifies  the  object  of  the  action  as  field 

Identifies  the  object  of  the  action  as  a set 

Identifies  the  object  of  the  action  as  a subset 

Specifies  resulting  position  of  set. 
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9.1.3  Noise  Words 

Noise  words  are  a group  of  commonly  used  words  which 
have  no  effect  on  the  functions  of  the  statement  but  which 
help  to  give  the  statements  a more  English-like  readability. 
Noise  words  can  appear  any  place  within  a statement.  The 
following  noise  words  are  allowed  in  NFL: 


A 

FOR 

IS 

WITH 

AN 

FROM 

THAN 

USING 

AS 

IN 

THE 

BY 

INTO 

TO 

Statement 

Labels 

The  provision  for  labeling  statements  (or  procedures) 
allows  a name  to  be  associated  with  a statement*  These 
names  can  then  be  referenced  as  exit  points  or  to  change  the 
sequence  of  execution.  Labels  must  begin  with  an  alpha 
character  and  nay  contain  only  alphameric  characters.  The 
label  can  contain  up  to  seven  characters.  It  is  identified 
as  a label  by  suffixing  the  name  with  a colon.  A valid 
label  must  have  a space  following  the  colon.  Statement 
identifiers  or  noise  words  cannot  be  used  as  labels. 

Example  - 

LOOP:  MOVE. ...GO  TO  LOOP 

LOOP  is  a label  associated  with  the  MOVE  statement.  In  the 
example,  the  GO  causes  the  order  of  execution  to  be  changed 
to  the  statement  labeled  LOOP. 

The  following  statements  may  not  have  labels: 

An  If  statement  or  any  part  of  an  IF  statement  such 
as  the  AND,  OR,  OR  ELSE  clause. 

A CONTINUE  statement 

A NOTE  statement 

A DEFINE  statement 
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9.1.5  Operands 

Statement  operands  identify  control  locations, 
subroutines  and  tables,  literal  values,  and  data  locations. 


9. 1.5.1  Control  Location  Operands 

Control  locations  are  references  to  statement  labels 
(section  9.2.4).  This  type  of  operand  is  an  exit  point  or 
a change  (GO)  in  execution  sequence. 

Exaaple  1 - 

LOCATE  SET  HEQPT, EXIT  TC  NOSUB 

In  this  exaaple,  if  there  are  no  subsets  belonging  to  the 
set  MEQPT,  the  next  stateaent  to  be  executed  would  be  the 
stateaent  with  the  label  NOSUB.  Thus  NOSUB  is  a "control 
location"  type  operand. 

Exaaple  2 - 

GO  TO  XYZ 

Hhen  the  above  statement  is  executed,  the  next  statement  to 
be  executed  would  have  the  label  XYZ.  XYZ  is  a "control 
location"  type  operand. 


9.1.5. 2 Subroutine/Table  Name  Operands 

Khen  user  written  subroutines  or  tables  are  to  be 
executed,  the  subroutine  or  table  naae  is  designated  as  a 
statement  operand. 

Example  - 

IF  LOC  IS  IN  TABLE  PLACES 

In  the  above  exaaple,  the  operand  PLACES  names  a user 
written  validation  table. 
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i 


i 


9. 1.5. 3 Literal  Value  Operands 

when  a value  is  specified,  it  is  a literal  value 
operand.  Alpha  or  numeric  literals  can  be  specified.  To 
designate  an  alpha  literal,  the  value  must  be  enclosed  in 
quotes.  Though  several  words  say  be  included  within  the 
quotes,  it  is  considered  as  a single  operand  (care  must  be 
taken  not  to  split  a literal  value  operand  over  aore  than 
one  card).  With  the  exception  of  the  quote  and  ampersand 
characters,  any  character  can  be  used  within  the  quotes.  To 
define  a literal  value  operand  containing  a quote  or 
ampersand,  a double  quote  or  ampersand  must  be  used.  In 
this  instance,  the  redundant  special  character  is  not 
counted  in  determining  the  length  of  the  literal. 

Numeric  literal  value  operands  are  designated  by 
expressing  a numeric  value  (not  enclosed  in  quotes) . A ♦ 
(plus)  or  - (minus)  sign  may  be  prefixed  to  the  value.  If 
the  sign  is  missing,  the  value  is  assumed  to  be  positive. 

Example  1 - 

MOVE  'ROSSLYN  PLAZA'  TO  LOC 

7\,  the  above  example,  the  alpha  literal  value  ROSSLYN  PLAZA 
.'i.i.1  be  moved. 

Example  2 - 

COMPOTE  SCALE  = tl 999  * LENGTH 

In  the  above  example,  the  numeric  literal  1999  will  be  used 
in  the  computation.  Note  that  in  the  exaaple  the  plus  sign 
could  be  oaitted. 


9. 1.5.  4 Data  Location  Operands 

Data  location  operands  are  designated  by  using  syabolic 
names  which  have  been  defined  to  the  system  in  such  a way 
that  the  name  is  equated  to  the  location  and  length  of  the 
data. 

The  location  and  length  may  be  modified  or  adjusted  for 
these  types  of  operands  (except  for  binary,  coordinate  and 
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variable  field  data)  by  use  of  partial  field  notation.  This 
is  done  by  following  the  symbolic  name  (separated  by  at 
least  one  blank  or  comma)  with  the  desired  beginning  and 
ending  character  positions.  The  fora  of  expression  for 
partial  field  notation  is  N/H  where  N is  the  beginning 
character  position  and  N is  the  ending  position;  e.g.,  to 
designate  the  first  two  characters  of  the  field  MEQPT, 
specify  MEQPT  1/2. 

There  are  four  basic  types  of  "Data  Location"  operands 
in  NFL.  These  are  file  data,  transaction  data,  indirect 
data,  and  defined  constants  and  areas. 


9. 1.5. 4.1  File  Data  Operands 

File  data  operands  ire  designated  by  the  symbolic  naae 
assigned  to  the  specific  value  (field)  during  file 
structure. 

Exanple  - 

IF  MEPSD  IS  EQUAL  TO  HERD! 

NEPSD  and  MERDY  are  file  data  operands. 


9. 1.5. 4. 2 Transaction  Data  Operands 

Transaction  data  operands  are  designated  by  the  syabolic 
naae  assigned  to  the  value  (field)  in  the  statement 
transaction  descriptor  deck.  The  symbolic  naae  is  always 
prefixed  with  a $ character.  Note:  NFL  does  not  permit  the 
TN/fl  fora  of  transaction  references. 

Example  - 

MOVE  {MEQPT  TO  MEQPT 
SMEQPT  is  a transaction  data  operand. 
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9. 1.5. 4. 3 Indirect  Data  Operands 

Indirect  data  operands  (see  section  7.2)  are  designated 
by  prefixing  the  symbolic  name  (defined  by  the  transaction 
descriptor  deck)  with  C$.  Partial  field  notation  is  not 
allowed  for  indirect  data  operands. 

Example  - 

POSITION  TO  THE  FIRST  SUBSET  FOR  C$ZILCH,EXIT  TO  NOS... 
C$ ZILCH  is  an  indirect  data  reference. 


9. 1.5. 4. 4 Defined  Constant  and  Area  Operands 

Constants  and  areas  which  can  be  used  as  work  areas  can 
be  defined  and  given  symbolic  names  by  the  user.  These  are 
then  referenced  by  symbolic  name  as  operands  in  statements. 

NFL  provides  three  constants  which  can  be  referenced  and 
need  not  be  defined  by  the  user.  These  have  the  following 
characteristics  and  symbolic  names. 

a.  For  a value  of  zero,  use  ZERO,  ZEROS,  or  ZEROES. 

b.  For  a value  of  blank,  use  BLANK  or  BLANKS. 

c.  For  the  current  date  and  time,  use  SYS DATE. 

SYSDATE  is  in  the  form  YYDDDTTTT  where  Y is  year,  D is 
Julian  date  and  T is  tine.  Partial-field  notation  will  not 
be  allowed  for  the  zero  and  blank  values. 


9.2  Special  Reguirements  and  Considerations 

There  are  several  special  requirements  or  considerations 
vhicn  are  imposed  by  NFL.  These  must  be  clearly  understood 
by  the  user  for  effective  application  of  NFL. 
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9.2.1  Data  Mode  Compatibility 

The  NFL  statements  are  not  "mode"  oriented,  therefore  it 
does  not  require  one  statement  for  alpha  data  and  another 
for  numeric.  Obviously,  only  numeric  data  may  be  used  in  an 
arithmetic  statement.  In  all  other  instances,  the  system 
checks  for  the  mode  of  the  data  and  determines  the  mode  of 
the  operation.  EBCDIC  work  areas  are  nonmode  associated  and 
take  on  the  node  of  the  related  data.  If,  when  two  operands 
are  specified,  both  are  nonmode  associated,  the  node 
defaults  to  alpha.  There  are  some  combinations  of  mode 
which  are  illegal.  Legal  node  combinations  are  given  in  the 
table  below. 

Mode  codes  are: 

A - alpha 
B - binary 
C - coordinate 
D - decimal 

N - nonnode  associated 
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Legal  Mode  Combination: 


Qperapd  1 


0£§EM4_2 


A 

A 

A 

B 

B 

B 

C 

C 

C 

D 

D 

D 

D 

D 

V 
N 

V 

V 
w 


A 

C 

V 
B 
D 
H 
A 
C 

V 

A Note  the  combinations 
C cannot  be  reversed 
B 
» 

D 

V 
B 
C 
0 
A 


9.2.2  Data  Length  Compatibility 

When  two  operands  for  a statement  require  data  length 
compatibility,  NFL  automatically  pads  or  truncates  to  obtain 
this  compatibility.  The  second  operand  length  is  the 
determining  length.  Alpha  data  fields  are  padded  with 
blanks  or  truncated  on  the  right.  Numeric  data  fields  are 
padded  with  zeros  or  truncated  on  the  left. 


9.2.3  Special  Statement  Sequence  Pequirements 

There  are  several  NFL  statements  or  groups  of  statements 
which  require  special  sequence  considerations.  These  are 
described  in  the  paragraphs  which  follow. 
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9.2.3. 1 Condition/Action  Statement  Sequence 

Condition  stateients  are  composed  of  conditional  clauses 
logically  connected  and  identified  by  IFs,  ANDs,  and  ORs. 
An  action  (s)  is  always  associated  with  a condition.  This 
action  is  executed  if  the  ccndition  is  true.  There  nay  also 
be  a set  of  "false"  actions  associated  with  a condition. 
False  actions  are  optional  and  identified  by  an  ELSE 
statenent.  After  the  "true"  or  "false"  actions  have  been 
executed,  the  point  at  which  execution  is  continued  is 
identified  by  a CONTINUE  statenent. 

There  nay  be  multiple  "true"  and  "false"  statements. 
All  stateaents  between  the  last  condition  clause  and  the 
ELSE  or  CONTINUE  statements  are  "true"  actions.  All 
statements  between  the  ELSE  and  the  CONTINUE  are  "false" 
actions. 

A second  condition  cannot  appear  between  the  first 
condition  and  the  actions  associated  with  it. 

For  labeling  purposes,  a condition/action  statement 
sequence  is  considered  to  be  a single  statement.  A label 
nay  precede  the  keyword  IF  but  no  further  labels  are 
permitted  until  after  the  keyword  CONTINUE. 

Example  1 - 

IF  MEPSD  IS  NOT  GT  HEREQ, AND  HEQPT  IS  EQUAL  TO 
'PLANE',  PRINT  •***', HEQPT, '*** DEFICIENCY***', 

MEPSD, HEREQ. 

CONTINUE, POSITION.. . . 

In  the  preceding  exanple,  if  the  condition  is  true  the 
action  PRINT  will  be  executed.  If  the  condition  is  false, 
or  on  completion  of  the  PRINT  action,  processing  will 
proceed  with  the  CONTINUE  statenent. 

Example  2 - 

IF  MEPSD  IS  NOT  GT  MEREQ, AND  HEQPT  IS 
EQUAL  TO  'PLANE',  PRINT  •***', HEQPT, 

'*** DEFICIENCY * ** ' , HEPS D,  HEPEQ. 

ELSE,  COHPUTE  DIF  = HEPSD  - HEREQ. 

CONTINUE,  POSITION... 
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In  tha  preceding  example,  if  the  condition  is  true,  the 
action  PRINT  will  be  executed.  If  the  condition  is  false, 
the  action  COMPUTE  will  be  executed.  In  either  case, 
execution  will  then  continue  at  the  CONTINUE  stateaent. 


9. 2. 3. 2 Procedure  Definitions 

Procedures  are  simply  a aethod  of  grouping  conditions 

and  actions  as  a unit  and  allowing  these  to  be  executed  as 

a unit.  The  first  stateaent  of  a procedure  is  the  PROCEDURE 
statement.  The  last  statement  is  an  END  statement.  All 
condition  and  action  statements  between  the  PROCEDURE  and 
END  statements  are  considered  as  part  of  that  procedure. 

A procedure  can  be  executed  by  executing  a GO  to  the 
procedure  from  outside  of  the  procedure  or  by  "dropping"  in 
it.  Upon  completion,  a procedure  will  return  control  to  the 
stateaent  following  the  GO  statement  (GO  type  execution)  or 
the  statement  following  the  procedure  END  statement 

("dropping"  type  execution)  . Exit  (return)  from  a procedure 

occurs  when  the  RETURN  statement  is  executed  or  when  the  end 
of  the  procedure  (END  statement)  is  encountered. 

Procedures  are  restricted  in  the  following  sense: 
execution  of  a procedure  can  only  be  initiated  at  the  entry 
point  of  the  procedure.  Nesting  (procedure  calling  a 
procedure)  is  not  permitted. 

The  examples  below  illustrate  the  two  methods  for 
executing  a procedure. 

Example  1 - 

...  52  to  floifi  result  to  I2X££... 

...SUM:  PROCEDURE  conditions  and  actions  END... 

The  preceding  example  illustrates  how  a procedure  is 
executed  from  a GO  stateaent. 

The  procedure  named  SUM  would  be  executed  when  the  GO  TO 
SUM  stateaent  is  executed.  When  the  END  stateaent  within 
the  procedure  is  executed  control  will  be  returned  to  the 
next  statement  following  the  GO  TO  SUM  stateaent.  Following 
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the  execution  of  the  procedure,  the  next  statement  to  be 
executed  would  be  the  HOVE  RESULT  TO  TOTAL  statement. 

Example  2 - 

...MOVE  SYSDATE  TO  DATE,  CONVERT:  PROCEDURE... 
procedure  conditions  and  actions  RETURN  additional 
procedures  conditions  and  actions  END  PRINT  'PILE 
UPDATED',  DATE... 

The  preceding  example  illustrates  the  "drop  through"  method 
of  executing  a procedure.  The  procedure  is  executed 
following  the  statement  HOVE  SYSDATE  TO  DATE.  When  the 
RETURN  statement  is  executed,  the  next  statement  to  be 
executed  would  be  the  first  statement  following  the  END 
procedure  statement  which  in  the  example  is  a PRINT 
statement. 


9. 2. 3. 3 Define  Seguence  Requirements 

There  are  two  simple  considerations  regarding  sequence 
requirements  for  use  of  DEFINE.  The  first  is  that  a 
constant  or  area  must  be  defined  before  it  can  be  referenced 
by  another  statement.  The  second  involves  the  define  and 
initialize  (VALUE)  statement.  The  initialization  occurs  at 
the  point  that  the  statement  is  encountered.  Thus,  in  a 
logic  statement  which  loops  bach,  an  area  might  be 
reinitialized  or,  if  the  path  of  execution  never  encountered 
the  initialize  statement  the  area  would  not  be  initialized 
during  that  execution. 

Though  not  required,  these  two  sequence  requirements  can 
always  be  satisifed  by  placing  all  define  statements  at  the 
beginning  of  the  NFL  logic  statement. 


9.2.4  Subset  Positioning 

Special  consideration  should  be  given  to  the  subset 
positioning  actions  which  position  to  the  next  subset.  If, 
at  the  time  the  statement  is  executed,  the  set  is  in  an 
inactive  status  (either  the  set  has  never  been  activated  or 
the  set  has  been  positioned  past  the  last  subset)  the  first 
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subset  of  the  set  will  be  activated.  If  there  are  no 
subsets,  the  exit  will  be  taken. 


9.3  NPL  Statement  Description 

This  section  describes  each  of  the  NFL  statements  in 
detail.  In  each  of  the  examples  which  are  given,  required 
terms  are  underscored.  Those  which  are  not  required,  such 
as  noise  words,  are  not  underscored.  Commas  and  periods  are 
optional;  i.e.,  they  are  not  required  and  are  effectively 
ignored.  A summary  of  the  syntax  for  the  NFL  can  be  found 
in  section  9.4. 


9.3.1  Conditional  Statements 

To  review  what  has  previously  been  stated  regarding  NFL 
conditional  statements: 

' n 

a.  The  statement  identifier  IF  introduces  the  first 
condition  clause  of  a new  conditional  "string". 

b.  AND  or  OP  identifiers  identify  a continuation  of 
the  conditional  string  and  the  logic  to  be  applied 
between  clauses. 

c.  A conditional  string  is  always  followed  by  a "true" 
action  (s),  optionally  a false  action  (s)  , and  a 
required  continuation  point. 

d.  A second  condition  nay  not  appear  before  the 
continuation  point. 

Several  types  of  conditional  clauses  in  NFL  are  listed 
below. 


Relational 
Table  Validation 
Picture  Hask 


Switch 
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Bit  Mask 
New  Record 
Run  Complete 
Overflow. 


9.3. 1.1  Relational  Conditicn 

The  relational  condition  is  used  to  compare  two  pieces 
of  data  for  a stated  relationship.  The  clause  is  composed 
of  an  operand,  a relational  operator,  and  a second  operand. 

Example  - 

if  EIfiI.fi A IS  SfiUAL  TO  ZiliDB... 

The  above  example  is  a typical  example  of  the  relational 
condition  clause.  The  operand  represented  as  PIBLDA  can 
reference  transaction  data,  data  file  data,  indirect  data, 
constants,  or  work  areas.  The  relational  operator  (EQUAL) 
could  be  any  one  of  the  following: 

EQ 

EQUAL  The  relationship  must  be  equal  to  be  true. 

EQUALS 

NE  The  relationship  must  be  unequal  to  be  true. 

LT  The  relationship  aust  be  less  to  be  true. 

LESS 

GT  The  relationship  aust  be  greater  to  be  true. 

GREATER 

LE  The  relationship  aust  be  equal  to  or  less  to  be 

true. 

GE  The  relationship  aust  be  equal  to  or  greater  to 

be  true. 

FIELOB  can  reference  transaction  data,  data  file  data, 
indirect  data,  constants,  work  areas  or  literal  values. 
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FIELDB  night  also 
operand  for  the  equal 


be  expressed  as  a aultiple 
(and  not  equal)  relationship. 


value 


Exaaple  - 

•••Aflfi  Hit  DA  IS  1QU.LL  TO  ' RQSSLYN'  , ' GBURG* . 

• UA I y IN G TO NT , . 7 . 


The  aultivalue  equal  condition  is  processed  as  an  OP 
string,  i.e.,  if  any  one  of  the  nultiple  values  satisfies 
the  desired  relationship,  the  clause  is  true.  This,  of 
course,  is  just  the  opposite  if  the  negative  relationship  is 
required . 


Exaaple  - 


. . . AN  £ FIglfDA  IS  HOT  EfiUAt  TO  'RQSSLYN',  ‘GBURG*, 
' “ASHING JO N ',  . . . 

In  this  exaaple,  for  FIELDA  to  be  true,  it  aust  not  equal 
•ROSSLYN*,  * GBURG*  , or  ‘WASHINGTON*. 

The  between  relationship  condition  requires  two  fields 
or  values  following  the  specified  relation. 

Exaaple  - 


...Qfi  Cmi!  is  fimiS!!  520^702... 

The  two  between  values  are  separated  by  a slash; 
aultiple  value  operands  are  allowed  with  the  between 
relationship. 

Exaaple  - 

IE  £IEL£  is  520^722,  922Z11££-.. 

The  results  (true  or  false)  of  the  aultiple  value 
between  is  the  saae  as  described  for  the  equal  relationship. 
The  between  relation  operator  can  be  expressed  as  BT  or 
BETWEEN. 

when  specifying  partial  field  notation  with  the  second 
operand  of  the  between,  care  aust  be  taken  to  be  sure  that 
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the  partial  £ield  notation  is  preceded  and  followed  by  at 
least  one  blank  (see  section  9.5). 


9. 3. 1.2  Table  Validation 

The  table  validation  condition  allows  the  user  to  use  a 
user-written  subroutine  or  table  lookup  for  validation 
purposes.  The  clause  is  specified  by  designating  the  data 
to  be  validated  and  the  table  (or  subroutine)  which  is  to  be 
executed  to  perfors  the  validation. 

Exaaple  - 


...Mfi  fielda  IS  IN  TABU  CNTRYS.  .. 

FIELDA  nay  be  transaction  data,  data  file  data,  indirect 
data,  constants  or  work  areas.  The  keyword  TABLE  could  also 
be  designated  as  TAB.  CNTRYS  is  the  naie  of  the  table  or 
subroutine. 

NOT  could  be  used  to  negate  the  condition. 

Exaaple  - 


...£&  Z1U2A  IS  N01  IN  TABLE  CNTRYS... 

The  validation  aust  be  unsuccessful  for  the  above  clause 
to  be  true. 


9. 3.1. 3 Picture  Mask 

The  picture  condition  allows  an  alpha  or  deciaal  value 
to  be  tested  for  designated  character  types.  A picture  aask 
aust  be  specified.  This  aask  is  coaposed  of  a series  of  the 
following  characters. 

A 

N 

S 


l9Sl 

Alpha  characters 
Nuaeric  characters 
Special  characters 
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B Blank  characters 

X Nonblank  characters 

Y Nonspecial  characters 

* No  check. 

The  field  to  be  tested  is  checked  character-by-character 
for  the  condition  specified  by  the  corresponding  character 
in  the  mask. 

Exaaple  - 


IXSlfi  IS  AS  IN  PICTURE  ' NNAAAN p ' 

The  above  exaaple  Mould  test  the  contents  of  PI  ELD  for 
two  nuaeric  followed  by  three  alpha  followed  by  two  nuaeric 
characters. 

FIELD  aay  reference  transaction  data,  data  file  data, 
indirect  data,  constants  or  work  areas.  The  aask  aust  be  an 
alpha  literal  value. 


9. 3. 1.4  Switch  Test 

The  switch  test  is  used  with  the  TURN  action  (see 
section  9.3. 2.8).  It  is  a tool  for  testing  for  an  ON/OFF 
condition  of  a switch  which  is  set  by  the  user. 

The  switch  is  a single  byte  (character)  in  core  which  is 
set  to  an  EBCDIC  zero  for  OPP  and  an  EBCDIC  one  for  OR.  The 
switch  is  designated  by  a syabol  which  can  be  defined  with 
a DEFINE  statenent  by  the  user  or  can  be  autonatically 
defined  by  the  systen. 

The  fora  of  the  switch  clause  is  operand,  followed  by 
the  keyword  OPP  or  ON. 


Exaaple  - 

...23  THE  22S»I£H  IS  ON... 


A 


\ 
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In  the  preceding  exaaple,  if  the  character  represented 
by  the  symbol  GOSNTCH  contains  a one,  the  clause  will  be 
true. 

The  switch  operand  can  only  be  a defined  area  (by  the 
user  or  systea) . 

The  keyword  (ON)  can  be  ON  or  OFF. 


9.3. 1.5  Bit  Mask  Test 

r he  bit  Bask  test  allows  a user  to  scan  a field  on  a 
character  basis,  while  testing  for  the  presence  of 
designated  bits  within  a character.  The  bit  mask  is 
specified  as  a series  of  ones  and  zeros.  If  less  than  eight 
are  specified,  zeros  will  be  padded  to  the  right.  If  aore 
than  eight  are  specified,  they  will  be  truncated  on  the 
left. 

When  an  ON  (or  NOT  OFF)  condition  is  specified,  if  any 
bit  in  any  character  of  the  field  being  scanned  Batches,  the 
result  is  true.  For  an  OFF  (or  NOT  OH)  conditon,  if  all  of 
the  designated  bits  in  any  character  of  the  field  being 
scanned  are  off,  the  result  is  true. 

The  fora  of  the  bit  test  is;  operand,  keyword  (BIT) , bit 
Bask,  keyword  (ON,  OFF,  NOT  ON,  or  NOT  OFF). 

Exaaple  - 

IE  Ellifi  BIT  10111111  IS  Ofi... 

In  the  preceding  exaaple,  if  any  bit  of  any  character  of 
FIELD  is  a one,  other  than  the  second  bit,  the  clause  will 
be  true. 

Example  - 

IF  EIEIE  BIT  101 IHH  IS  OFF... 

In  this  exaaple,  a true  condition  will  result  only  when 
all  of  the  bits,  or  all  bits  but  the  second,  are  zero  for 
any  character  of  FIELD. 
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The  bit  mask  is  designated  as  an  unsigned  numeric 
literal  value  composed  of  ones  and  zeros. 


9.3. 1.6  New  Record  Test 

When  a file  record  cannot  be  found  for  a transaction,  a 
new  file  record  is  automatically  created  by  the  File 
Maintenance  capability.  There  are  times  when  the  user  would 
like  to  know  when  this  condition  exists.  This  can  be 
determined  by  the  new  record  test.  The  example  below 
illustrates  how  to  specify  this  condition. 

Example  - 

. . . AND  NEW  RECORD . . . 

The  next  example  illustrates  how  a test  for  an  old  record 
could  be  designated  by  use  of  the  condition  negation. 

Example  - 

...  OR  HOT  NSW  RECORD. . . 


9. 3. 1.7  Job  Complete  Test 

For  the  user  who  wishes  to  perform  an  action  at  the  end 
of  the  maintenance  run,  the  job  complete  test  is  provided. 
This  test  is  particularly  useful  in  producing  "maintenance 
summaries".  It  would  only  be  used  in  Range  logic 
statements. 

The  following  example  illustrates  how  the  job  complete 
test  would  be  used  to  test  for  the  end  of  the  run  and  for 
not  the  end  of  the  run. 
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Example  - 


...IF  THE  JOB  IS  COMPLETE AND  THE  JOB  IS  NOT 

COMPLETE  ... 


9. 3. 1.8  Overflow  Test 

The  test  for  OVERFLOW  statement  is  used  after  a compute 
statement  to  determine  whether  overflow  has  occurred.  The 
test  must  be  made  before  a second  COMPfITE  statement  is 
executed  or  the  status  of  the  first  statement  is  lost.  The 
example  following  illustrates  the  overflow  test. 


Example  - 

•••IX  OVERFLOW  IS  ON IF  OVERFLOW  IS  OFF... 


9.3.2  Action  Statements 

Action  statements  specify  a function  to  be  performed. 
The  operations  which  they  specify  to  be  performed  may  be 
unconditional  or  they  may  be  based  on  the  satisfaction  of  a 
prior  condition. 


9.3.2. 1 Data  Movement 

There  are  two  statements  which  can  be  used  to  move  data 
from  a specified  source  to  a specified  destination. 


9. 3.2. 1.1  The  MOVE  Statement 

There  are  two  forms  of  the  HOVE  statement.  The  first  is 
a simple  movement  of  the  data  from  a source  location  to  a 
destination  location.  The  second  is  the  movement  of  the 
data  from  a source  location  via  a conversion  subroutine  or 
table. 

Example  - 

...flOVfi  FIEIfPA  TO  FIELDS.  . . 
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The  preceding  exaaple  illustrates  a sieple  HOVP 
statement.  FIELDA  aay  reference  transaction  data,  data  file 
data,  indirect  data,  defined  constants,  defined  work  areas 
or  literal  values.  FIELDB  aay  reference  data  file  data, 
indirect  data  or  defined  work  areas.  Data  node 
coapatibilit ies  will  autonatically  be  checked  and  field 
lengths  will  autoaatically  be  adjusted.  If  partial  field 
notation  is  designated,  it  will  be  checked  to  deternine 
whether  it  is  within  the  boundaries  of  the  data  field.  Mhen 
moving  coordinate  fields,  to  or  fron  EBCDIC  fields, 
conversion  to  and  fron  internal  format  autoaatically  occurs. 

Example  - 


...flOVfi  FIELDA  TO  fJELD B USING  TAB^E  STATES. 

BUI  ILL  ST... 

The  preceding  exaaple  illustrates  the  movement  of  data 
through  a conversion  table.  FIELDA  and  FIELDB  nay  reference  ) 

the  sane  types  of  data  as  for  the  simple  move.  The  data 
characteristics  for  FIELDA  are  checked  against  the  input 
characteristics  for  table  STATES  and  the  FIELDB  data 
characteristics  are  checked  against  the  output 
characteristics  for  table  STATES.  The  exit  label  (ILLST)  is 
the  label  of  the  NFL  statement  to  which  control  will  be 
given  if  the  table  is  not  successful  in  converting  the  data. 

In  either  of  the  HOVEs,  FIELDA  may  not  be  a variable 
data  file  field  or  set.  If  FIELDB  is  a variable  data  file 
field  or  set,  am  existing  va£iabl£_  £gtg_  in  FI5I&B  "ill  be 
replaced  fey.  the  contents  q£  PjELftA.  if  FIELDB  is  a major 
control  field,  a warning  diagnostic  will  be  printed  when  the 
logic  statement  is  compiled  and  the  move  will  be  allowed. 

IP  FIELDB  is  a secondary  control  field  (subset  ID) , the  move 
will  be  allowed  without  any  warning  diagnostic  to  the  user. 

Note:  tthen  alpha  or  decimal  data  is  moved  to  an  alpha  or 
decimal  field,  the  •HOVE'  instruction  uses  a 360  ALC  HOVE 
instruction  which  moves  left  to  right  through  each  field  one 
byte  at  a time.  Therefore,  caution  must  be  used  whenever 
overlapping  portions  of  the  sane  field  are  used  as  the 
operands  of  a 'MOVE*  instruction  (e.g.  HOVE  FIELDA  2/4  TO 
FIELDA  3/5...). 
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9.3. 2. 1.2  The  ATTACH  Statement 

The  ATTACH  statement  is  used  only  to  move  data  to  a 
variable  set.  It  differs  fro*  the  MOVE  to  variable  set  in 
that  instead  of  replacing  the  existing  contents,  the  data  to 
be  moved  is  appended  to  the  existing  data. 

Exanple  - 


• • • ill iC H FI ELD A TO  FIELDB. . . 

In  the  preceding  example,  assuming  that  FIELDB  is  a 
variable  set,  the  contents  of  FI  EL DA  mould  be  appended  to 
the  existing  contents  of  FIELDB.  FIELDA  may  reference 
transaction  data,  data  file  data,  indirect  data,  defined 
constants,  defined  work  areas  or  literal  values.  FIELDB  may 
reference  data  file  data  which  are  variable  sets. 


9.3. 2.2  The  COMPUTE  Statement 

The  COMPUTE  statement  is  used  to  specify  one  or  more 
arithmetic  operations  and  to  store  the  result  in  the 
designated  result  field.  The  general  format  of  the  COMPUTE 
statement  it.  the  result  field  followed  by  the  = (egual 
character)  followed  by  the  arithmetic  expression. 

Example  * 

COMPUTE  FIELDA  = Arithmetic  Expression 

In  the  preceding  example,  the  final  result  of  the 
expression  to  the  right  of  the  = character  will  be  placed  in 
the  location  designated  as  FIELDA.  FIELDA  may  reference 
data  file  data,  indirect  data  or  defined  work  areas. 

The  arithmetic  expression  can  consist  of  operands 
separated  by  arithmetic  operators.  The  operands  may 
reference  transaction  data,  data  file  data,  indirect  data, 
defined  work  areas,  defineu  constants  or  numeric  literals. 
The  arithmetic  operator  may  be  a ♦ - * / character 
indicating  addition,  subtraction,  multiplication,  or 
division.  The  arithmetic  operator  must  be  preceded  and 
followed  by  a blank  character. 
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Parentheses  aay  be  used  to  alter  the  sequence  of 
arithmetic  operations.  Expressions  within  parentheses  are 
evaluated  first.  When  parenthesized  expressions  are  in  a 
nest  of  parentheses,  evaluation  begins  at  the  innermost 
level  and  continues  until  the  outermost  parenthesis  level  is 
reached . 

The  multiplication  and  division  operators  are  at  a 
higher  precedence  level  than  the  addition  and  subtraction 
operators.  In  expressions  containing  consecutive  equal 
precedence  operators,  evaluation  will  be  performed  from  left 
to  right. 

Note:  Only  integer  arithmetic  may  be  performed.  Division 
of  a value  by  a larger  value  produces  a zero  result. 
Therefore,  careful  consideration  must  be  given  to  the 
sequence  of  operations.  Full  word  binary  logic  is  used,  so 
the  maximum  value  resulting  from  any  operation  is  restricted 
to  ±2,147,483, 647. 

Example  - 

A*  B-C*D/E 

The  preceding  expression,  because  of  the  order  of  process- 
ing would  have  the  same  result  as 

(A*  B)  - ( (C*D)  /E) 


while 


A*B*OD/E 

would  have  the  same  result  as 
(At  (B*C) ) - (D/E) 


9. 3. 2. 3 Subset  Positioning  Statements 

To  reference  a data  field  belonging  to  a periodic  set, 
that  set  must  be  activated  or  be  pointing  to  a subset, 
belonging  to  that  set.  NFL  provides  three  statements  to 
perform  the  functions  of  activating  and  "stepping"  through 
a set;  each  statement  has  an  exit.  The  exit  designates  the 
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label  of  the  stateaent  to  be  given  control  if  there  are  no 
subsets  or  if  a set  becones  exhausted. 


9. 3. 2. 3.1  The  LOCATE  Statement 

The  LOCATE  statement  will  activate  the  first  subset  of 
a set. 

Example  - 

...LOCATE  5 El  FIELDA  , EJIT  NOSS... 

The  preceding  example  would  cause  the  first  subset  of 
the  set  in  which  FIELDA  belongs  to  be  activated.  If  there 
are  no  existing  subsets  for  that  set,  control  would  be  given 
to  the  stateaent  following  the  label  NOSS.  FIELDA  may 
reference  a data  file  field,  indirect  data,  or  the  actual 
set  number  may  be  designated.  The  exit  label,  NOSS,  nay  be 
the  label  of  any  stateaent  other  than  a procedure  label. 


9.3.  2.3.  2 The  STEP  Statement 

The  STEP  statement  will  cause  the  next  subset  of  a set 
to  be  activated. 

Example  - 

...STEP  SE1  flELDA  , E£I!  ENDSET. .. 

In  the  preceding  example,  the  next  subset  of  the  set  in 
which  FIELDA  is  a field  will  be  made  active.  If  there  are 
no  other  subsets  to  be  made  active  the  exit  will  be  taken. 
FIELDA  may  be  referenced  as  a data  file  field,  indirect  data 
or  as  the  actual  set  number.  The  exit  label,  ENDSET,  may  be 
the  label  of  any  stateaent  other  than  a procedure  label. 


9. 3. 2. 3. 3 The  POSITION  Statement 

The  POSITION  stateaent  can  be  used  for  all  subset 
positiobing.  The  basic  positioning  actions  which  can  be 
done  with  the  POSITION  statement  are: 


j 
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a.  The  POSITION  statement  can  be  used  to  position  set 
to  the  first  subset  within  the  set. 

Example  - 

•••E2SIXIP.8  TO  THE  IISST  SUBSET  POP  FIELDA  , EjC^T 
N05§... 

The  preceding  example  would  cause  the  first  set  of  the 
set  in  which  FIELDA  belongs  to  be  activated.  If  there  are 
no  subsets  belonging  to  that  set,  control  will  be  given  to 
the  statement  following  the  label  NOSS  which  must  not  be  a 
procedure  label.  FIELDA  may  reference  a data  file  field, 
indirect  data  or  as  the  actual  set  number. 

b.  The  POSITION  statement  can  be  used  to  position  a 
set  to  the  next  subset  in  a set. 


Example  - 


...PQSIXIOJI  TO  THE  NEJJT  SUBSET  FOR  PIELfiA  , EXIT  TO 
END SET. . . 

The  preceding  example  would  cause  the  next  subset  for 
the  set  in  which  FIELDA  belongs  to  be  made  active.  If  there 
is  no  additional  subset,  control  will  be  given  to  the 
statement  following  the  label  ENDSET  (must  not  be  a 
procedure  label).  FIELDA  may  reference  a data  file  field, 
indirect  data  or  be  the  actual  set  number. 

c.  The  POSITION  statement  can  be  used  to  position  a 
set  after  the  last  subset  in  a set.  This  is  a 
useful  tool  to  build  a new  subset  at  the  end  of  a 
set. 


Example  - 

...POSITION  AFTER  LAST  SUBSET  FOR  EJJifiA... 

The  preceding  example  would  cause,  in  effect,  the  next 
action  for  that  set  to  be  after  the  last  subset  of  the  set 
(the  only  valid  action  against  that  set  would  be  build 
subset  or  delete  set) . Note  that  there  is  no  exit  in  the 
example.  An  exit  can  be  specified;  however,  the  exit  will 
never  be  executed,  i.e.,  it  is  ignored.  FIELDA  may 
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reference  data  file  data,  indirect  data,  or  be  the  actual 
set  number. 

d.  The  POSITION  statement  can  be  used  ,to  position  a 
set  to  the  subset  in  which  a designated  field  of 
that  set  contains  a designated  value. 


Example  - 

..  .PORTION  TO  FIELDA  IN  FIELDB.  EXIT  TO  NO  HIT. . . 

The  preceding  example  would  cause  the  following: 

If  the  set  in  which  FIELDB  belonged  was  inactive,  the 
first  subset  would  be  activated  and  the  contents  of 
FIELDB  compared  with  the  contents  of  FIELDA.  If  an 
egual  condition  exists  that  subset  will  be  activated. 
Otherwise,  the  set  containing  FIELDB  will  be  stepped  and 
the  compare  made  until  an  equal  condition  exists  or  the 
set  becones  exhausted. 


If  the  set  has  no  subsets  or  if  it  is  exhausted  without 
an  equal  condition,  control  will  be  given  to  the  next 
statement  following  the  NOHIT  label  (may  not  be  the 
label  of  a procedure)  . 

If  when  the  statement  is  executed,  a subset  of  the  set 
to  which  FIELDB  belongs  is  active,  the  subset  will  be 
stepped  and  the  compares  will  commence  with  that  subset. 

Note:  If  a set  is  stepped  past  the  last  subset  (effectively 
the  set  becomes  inactive) , the  next  execution  of  the 
POSITION  statement  will  cause  the  search  to  begin  with  the 
first  subset. 

In  the  preceding  example,  FIELDA  nay  reference 
transaction  data,  data  file  data,  indirect  data,  defined 
constants,  defined  work  areas  or  literal  values.  FIELDB  nay 
reference  a data  file  field  or  indirect  data. 
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9.3. 2.4  Auxiliary  Output  Statements 

There  are  four  forms  of  auxiliary  output  available  in 
NFL.  The  statements  to  format  and  output  each  form  are 
identical  except  for  the  statement  identifier  and  the  number 
of  devices  which  can  be  designated.  The  data  to  be  output 
is  specified  as  a list.  NFL  automatically  formats  the  data 
as  a continuous  string  of  data.  If  the  value  is  binary,  it 
will  be  converted  to  an  EBCDIC  value.  The  converted  length 
of  a binary  data  file  value  will  be  the  length  designated 
when  the  file  was  structured.  The  converted  length  of  a 
binary  work  area  will  be  10  characters.  Coordinates  which 
are  in  internal  form  will  be  converted  to  external  form.  If 
the  coordinate  was  defined  as  a field,  the  resulting  length 
will  be  that  designated  when  the  file  was  structured.  If 
the  coordinate  was  defined  as  a group,  the  resulting  length 
will  be  15  characters  per  point.  Blanks  are  not 
automatically  inserted  between  data  values.  If  they  are 
desired,  they  must  be  designated  by  the  user.  If  the  system 
provided  constants,  BLANK,  BLANKS,  ZERO,  ZEROS  or  ZEROES  are 
designated  for  output,  the  length  will  be  one  character. 
The  list  of  operands  to  be  output  may  be  transaction  data, 
data  file  data,  defined  constants,  defined  work  areas  or 
literal  values.  The  total  number  of  bytes  specified  by  all 
auxiliary  output  instruction  operands  cannot  exceed  994. 
NIPS  adds  six  bytes  to  the  specified  data  and  the  DCB  LRECL 
is  1000.  Violation  of  this  limit  will  result  in  a System 
001  ABEND  (I/O  ERROR,  RECORD  TOO  LONG). 


9. 3. 2. 4.1  The  PRINT  Statement 

The  PRINT  statement  is  used  to  log  data  on  a printer 
during  a FM  update  run.  Two  printers  can  be  designated.  If 
a printer  is  not  designated  in  the  PRINT  statement,  the 
default  is  printer  1.  In  the  TP  mode,  printer  1 designates 
the  display  terminal  and  printer  2 an  OMQ  display  device. 

Example  - 

...PRINT  IIEifiA,*  *,  FIELDB , * «,^IELDC... 

•••EfilHI  21i  Zf  FIELDB,  FIELDC. 
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The  first  exaaple  illustrates  the  PRINT  statement 
defaulting  to  printer  1;  the  second  illustrates  the  method 
for  specifying  the  printer. 

Note:  The  printer  specification  (on  N,  where  N is  1 or  2) 
■ust  immediately  follow  the  statement  identifier.  If  the 
total  length  of  data  is  greater  than  132  characters,  lines 
of  132  characters  will  be  printed  until  the  total  length  is 
exhausted. 


9. 3.2.4. 2 The  PUNCH  Statement 

The  PUNCH  statement  is  used  to  punch  data  onto  cards. 
Two  punches  can  be  specified.  If  a punch  is  not  specified, 
default  is  to  punch  1. 

Example  - 


...PJ1NCH  FI  ELD  A,  FIELDS  , PI  EL  DC... 

The  preceding  example  would  result  in  the  contents  of 
FIELDA,  FIELCB  and  FIELDC  being  punched  in  cards.  If  the 
total  length  is  greater  than  BO  characters,  80-character 
records  will  be  punched  until  the  total  number  of  characters 
is  exhausted. 


9. 3. 2. 4. 3 The  WRITE  Statement 

The  WRITE  statement  is  used  to  output  data  on  a 
sequential  output  file.  As  many  as  five  output  devices  can 
be  designated.  If  the  device  is  not  designated,  it  defaults 
to  auxiliary  device  1;  i.e.,  the  device  specified  on  the 
FN.AUX1  DD  card. 

Example  - 

£UX£  2M  3.  HELD  A,  FIEIDC... 

The  preceding  exaaple  would  cause  the  contents  of 
FIELDA,  FIELDB  and  FIELDC  to  be  formatted  and  a record  equal 
to  the  total  length  output  on  auxiliary  output  device  3. 
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9. 3. 2. 4. 4 The  DISPLAY  Statement 

The  DISPLAY  statement  is  provided  to  assist  the  terminal 
operator  in  correcting  erroneous  transaction  data  when  using 
the  online  update  capability  of  Source  Data  Automation 
(SODA)  . 

Example  - 

....DISPLAY  SPIELD,  'TUBE  MESSAGE'.. 

Nhen  this  instruction  is  executed  during  a SODA  run,  it 
causes  the  displayed  transaction  field  (SPIELD)  to  be 
underscored  with  a key  to  the  message  provided  as  the 
literal  'TUBE  MESSAGE'. 

When  this  instruction  is  executed  during  a batch  PM  run, 
it  causes  the  message  to  be  printed  on  the  Ordinary 
Maintenance  error  log  (see  section  6.2.9). 


9. 3. 2. 5 The  BUILD  Statement 

The  BUILD  statement  causes  a new  subset  to  be  created. 
The  new  subset  is  created  at  the  point  where  that  set  is 
active;  i.e.,  if  the  set  has  not  been  positioned  after  the 
last  subset  processed,  existing  subsets  are  "pushed  down"  in 
the  set  and  the  newly  created  subset  inserted  at  the  active 
point.  After  the  subset  has  been  created,  the  new  subset  is 
made  active.  No  data  is  moved  to  the  subset  as  a result  of 
the  BUILD  statement. 

Example  - 

...BiiliD  SUBSET  PIELDA.  .. 

The  preceding  example  causes  a new  subset  to  be  built 
for  the  set  in  which  PIELDA  belongs.  PIELDA  may  be  data 
file  data,  indirect  data  or  the  actual  set  number. 
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9. 3. 2.6  The  DELETE  Statement 

The  DELETE  statement  is  used  either  to  delete  the 
record,  to  delete  a set,  to  delete  the  currently  active 
subset,  or  to  clear  a field. 

a.  The  DELETE  record  is  illustrated  in  the  following 
example. 

Example  - 

•••Jl£UX£  RECORD.  .. 

The  preceding  example  informs  FM  that  the  current  data 
record  is  to  be  deleted.  After  execution  of  this 
instruction,  no  further  processing  is  performed  against  the 
current  data  record  and  a return  is  made  to  FM. 

b.  The  DELETE  set  is  illustrated  in  the  following  J 

example. 

Example  - 

...DEiJBU  SET  FOR  FIELD  A 

The  preceding  example  causes  the  entire  set  to  which 
PIELDA  belongs  to  be  deleted.  FIELDA  may  be  data  file  data, 
indirect  data  or  the  actual  set  number. 

l 

c.  The  DELETE  subset  is  illustrated  in  the  following 
example. 

Example  - 

•.•fiElfilS  THE  SUBSET  POR  FIELDA...  _ 

The  preceding  example  would  cause  the  currently  active 
subset  for  the  set  in  which  FIELDA  belongs  to  be  deleted. 

After  the  subset  is  deleted,  the  next  subset  (if  any)  is 
made  active.  FIELDA  nay  be  data  file  data,  indirect  data  or 
the  actual  set  number. 


d.  The  DELETE  field  is  illustrated  in  the  following 
exanple. 
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Example  - 

...UUU  PI  ELD  PI  ELD  A.  . . 

The  preceding  example  would  cause  one  of  the  following 
results  depending  on  PIELDA: 

o If  numeric,  PIELDA  would  be  set  to  zero. 

o If  alpha,  PIELDA  would  be  set  to  blanks. 

o If  a coordinate,  PIELDA  would  be  set  to  zero. 

o If  a variable  field  or  set,  the  variable  field 
or  set  would  be  deleted. 


9. 3. 2. 7 The  DEPINE  Statement 

J 

The  DEPINE  statement  is  used  to  define  constants  and 
work  areas.  A constant  is  sinply  a way  to  define  a literal 
value  which  can  be  referenced  with  a symbol.  Data  cannot  be 
moved  to  a constant.  Hork  areas  are  just  what  the  name 
implies,  and  are  used  for  the  temporary  storage  of  data. 

' 

There  are  two  types  of  work  areas.  One  is  a system 
provided  logic  statement  work  area  consisting  of  a 999-byte 
EBCDIC  area  and  a 20  full  word  binary  area.  Data  can  be 
\ passed  from  one  logic  statement  to  another  or  retained 

between  data  records  by  use  of  this  type  of  work  area.  The 
second  type,  or  logic  statement  internal  work  area,  is 
unigue  to  the  logic  statement  in  which  it  is  defined.  Any 
data  which  is  moved  to  it  is  lost  between  data  records. 

Each  define  assigns  a symbol  to  the  work  area  or 
constant.  The  symbol  is  then  used  to  reference  the  area  or 
constant.  An  error  will  occur  if  the  same  symbol  is  defined 
more  than  once  or  if  a defined  symbol  is  the  sane  as  a data 
file  field  name. 


9.  3.  2.  7.1  Defining  a Constant 

The  following  examples  illustrate  how  a constant  is 
defined. 
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Example  - 

...DEPINE  iJEADIfi  AS  '1IST  OP  RECORD  IDS  UPDATED*  ... 

•••DELifil  II  AS  *314. .. 

In  the  first  example,  HEADER  is  the  symbol  assigned  to 
the  alpha  literal  value.  Nhen  that  symbol  is  referenced  in 
a NFL  statement  the  literal  value  will  be  used.  In  the 
second  example,  PI  is  the  symbol  assigned  to  the  numeric 
value. 


9. 3. 2. 7. 2 Defining  an  Inter-logic  Statement  Work  Area 

Io  define  an  area  in  the  system  provided  EBCDIC  wort 
area,  one  identifies  the  symbolic  name  to  be  assigned  to  the 
area  and  the  relative  positions  within  that  area  in  the  fora 
HN/M  where  N is  the  relative  position  of  the  first  character 
and  M is  the  relative  position  of  the  last  character. 

Example  - 

•••DEPINE  SAVE  AS  W71/80... 


In  the  preceding  example,  SAVE  is  the  symbolic  name 
assigned  to  characters  71  through  80  of  the  EBCDIC  work 
area.  These  characters  can  then  be  referenced  by  the  NPL 
condition  and  action  statements  by  the  symbolic  name,  SAVE. 

Defined  areas  in  the  EBCDIC  work  area  can  be  overlapped. 
Example  - 

• ••yum  m as  j uz2... 


...DEFINE  fiOjJT H AS  W3/5... 
• • • £E£I£ E YEAR  AS  l&J.  . . 
...yum  DATE  AS  HI/7.  .. 


In  these  examples,  DATE  overlaps  DAI,  MONTH,  and  TEAR. 
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A binary  work  area  is  assigned  a symbolic  naie  by 
identifying  the  naie  followed  by  the  designated  word  in  the 
fora  BN  where  N is  a word  number  between  1 and  2j>  inclusive. 

Exaaple  - 

. ..DEFINE  COUNT  AS  B4... 

In  the  preceding  example,  COUNT  is  the  symbolic  name  to 
be  assigned  to  the  fourth  binary  word  in  the  system-provided 
binary  work  area. 


9. 3.2.7. 3 Defining  an  Intra-logic  Statement  Work  Area 

A logic  statement  internal  work  area  is  defined  by 
specifying  the  symbolic  name  and  designating  the  number  of 
characters  to  be  assigned  to  that  symbolic  name.  The  number 

of  characters  is  designated  by  the  form  #N  where  N is  the  j 

number  of  characters  to  be  assigned. 

Example  - 

...define  HOLD  AS  MO/... 

In  the  preceding  example,  a 10-character  area  will  be 
reserved  and  can  be  referenced  using  the  symbolic  name  HOLD. 


9. 3. 2. 7. 4 Defining  and  Initializing  an  Area 

A work  area  can  be  defined  and  initialized  with  a value 
each  iiia  that  the  logic  statement  is  ex§£]Jted.  when  using 
this  capability,  the  define  sequence  requirements  (section 
9.2. 3.3)  should  be  considered.  To  specify  that  a defined 
area  is  to  be  initialized  with  a value,  the  area  definition 
(sections  9. 3. 2.7. 2 and  9. 3. 2. 7. 3)  is  followed  by  the 
Keyword  VALUE  followed  by  the  literal  value  or  one  of  the 
system-provided  constants  (SYSDATE,  ZERO,  ZEROS,  ZEROES, 
BLANK,  or  BLANKS)  . 

Example  - 

...Jisms  SME  AS  H71/80.  VALUg  IS  BJ.  ANjC. . . 

■ 
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In  the  preceding  example,  a 10-character  area  in  the  1 

system  work  area  will  be  assigned  the  symbolic  name  SAVE. 

That  area  will  be  initialized  to  blanks  each  time  the  logic 
statement  is  executed. 

| 

Example  - 

1 

• •DEFINE  COO NT  AS  B4,  VALUE  IS  0... 

In  the  preceding  example,  the  binary  work  area  will  be 
assigned  the  symbolic  name  COUNT.  Each  time  that  the  logic  < 

statement  is  executed,  it  will  be  initialized  to  zero.  1 

; 

Example  - 

J 

I . . REFINE  HOLD  AS  JMO,  VALUE  IS  • ABCDEFGHIJ  • 

j 

In  the  preceding  example,  the  10-character  work  area 
will  be  assigned  the  symbolic  name  HOLD.  Each  time  that  the  j 

logic  statement  is  executed,  it  will  be  initialized  to  the  \ 

value  ABCDEFGHIJ. 

' 

I 9. 3.2.8  The  TURN  Statement 

The  TURN  statement  is  used  to  set  a 1 -character  area  to 
an  ON  or  OFF  status.  The  area  may  be  defined  by  the  user 
with  a DEFINE  statement  or  he  can  let  the  system  define  it 
for  him.  It  the  system  defines  the  area,  it  will  be  a logic  i 

statement  internal  work  area. 

The  TURN  statement  is  primarily  for  use  with  the  switch 
test  condition.  The  user  designates  the  switch  setting  he 
desires  to  be  set  with  the  TURN  statement.  Later,  he  can 
test  for  that  condition  with  the  switch  condition.  The 
switch  is  set  to  an  EBCDIC  zero  for  off  or  one  for  on. 

* 

Example  - 

.. .TURN  S WITCH  A ON. .. 

In  the  preceding  example  the  area  (switch)  having  the 
symbolic  name  SWITCHA  will  be  set  to  an  EBCDIC  one.  If  no 
area  has  been  defined  with  the  symbolic  name  SWITCHA,  an 
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area  will  automatically  he  defined  and  given  the  symbolic 
name  SWITCHA. 

SWITCHA  may  only  reference  defined  (by  the  user  or 
system)  areas. 


9. 3. 2. 9 Execution  Sequence  Changing  Statements 

There  are  two  NFL  statements  (not  counting  exits  from 
other  action  statements)  which  alter  or  change  the  sequence 
of  executing  statements. 


9. 3. 2. 9.1  The  GO  Statement 

Normally,  NFL  statements  are  executed  sequentially  in 
the  order  that  they  are  read  into  the  system.  The  GO 
statement  can  be  used  to  change  that  order.  Only  a 
statement  label  can  be  designated  as  the  point  to  continue 
execution.  That  label  nay  be  a procedure  label  (unless  the 
GO  is  inside  a procedure  definition  (see  section  9. 2. 3. 2)) 
or  a statement  label.  If  it  is  a statement  label,  it  must 
be  at  the  same  level  (within  or  without  a procedure)  as  the 
GO  statement.  If  a GO  to  a procedure  label  is  executed, 
return  from  the  procedure  will  be  to  the  next  sequential 
statement  following  the  GO.  If  it  is  not  a procedure  label, 
control  is  not  automatically  returned. 

Example  - 


...20  TO  J^OG  E£SE...  ...1,22:  EEIE1. . . 

The  preceding  example  illustrates  a typical  use  of  the 
GO  statement.  Assuming  that  a condition  precedes  the  GO 
statement,  if  the  condition  is  true,  the  order  of  statement 
execution  is  changed  to  the  statement  following  the  label 
LOG.  It  is  not  a procedure  statement,  thus  control  will  not 
be  returned. 

Example  - 

...22  TO  2211,  MOVE. . . ...22a:  EROCEDUgE... 
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s The  preceding  example  illustrates  the  use  of  the  GO 

stateaent  to  execute  a procedure.  When  the  procedure  has 
coapleted  execution,  execution  would  resuae  with  the  MOVE 
statement  following  the  GO  stateaent. 


9. 3. 2. 9. 2 The  RETURN  Stateaent 

The  RETURN  statement  when  used  within  a procedure 
returns  control  to  the  mainline  statement  or  when  used  in 
the  mainline,  terminates  execution  of  the  logic  stateaent. 
If  control  by  the  procedure  was  gained  from  a GO  statement 
(see  section  9.2.3. 2),  execution  of  the  RETURN  statement 
would  cause  control  to  be  returned  to  the  next  stateaent 
following  the  GO.  If  control  was  gained  by  the  procedure  by 
the  "drop  through"  method,  execution  of  the  RETURN  statement 
will  cause  control  to  be  returned  to  the  next  statement 
following  the  procedure  ENt)  statement. 

The  RETURN  stateaent  has  no  operands.  Examples  in 
section  9.2. 3.2  illustrate  the  use  of  the  RETURN  stateaent. 


9.3.3  Control  Point  Identifiers 

There  are  several  statements  which  cause  no  condition  to 
be  satisfied  or  action  to  be  performed.  Their  primary 
function  is  to  identify  statement  groupings  or  control 
points. 


9. 3. 3.1  The  NOTE  Statement 

The  NOTE  stateaent  actually  is  not  even  a control  point. 
It  is  simply  a means  for  the  user  to  insert  commentary  text 
between  NFL  statements. 

The  NOTE  statement  has  one  operand.  It  is  an  implicit 
literal  enclosed  in  guotes.  The  NOTE  statement  can  appear 
between  any  two  statements  but  should  not  appear  between  a 
label  and  its  associated  stateaent. 

Example  - 

...H2XB  2AXA  2^5  to  mqnbuc  soie  • mo nx h OfiU  XQ  wq£K 
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area* 

In  the  preceding  example,  the  NOTE  statement  is  used  to 
explain  the  characters  being  mowed. 


9.3.  3.  2 The  PROCEDURE  Statement 

The  PROCEDURE  statement  identifies  the  beginning  of  a 
group  of  statements  which  will  be  treated  as  a unit.  The 
PROCEDURE  must  be  preceded  ty  a label.  This  label  is  called 
the  procedure  name. 


9. 3. 3.3  The  END  Statement 

The  END  statement  identifies  two  control  points.  It 
identifies  the  end  of  a procedure  and/or  it  identifies  the 
end  of  the  logic  statement.  It  has  no  operands. 

Example  - 


NFL  Conditions  and  Actions 

PR0C1:  PROCEDURE 
Conditions  and  Actions 
END 

PR0C2:  PROCEDURE 
Condition  and  Actions 
END 

END. 

The  preceding  example  illustrates  a logic  statement 
containing  two  procedures.  The  first  END  statement 
encountered  terminates  the  group  of  statements  which 
comprise  procedure  PR0C1.  The  second  END  statement  does  the 
same  for  the  procedure  PR0C2.  The  third  END  statement 
terminates  the  entire  logic  statement. 
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9. 3. 3. 4 The  ELSE  Statement 

The  ELSE  statement  identifies  the  beginning  of  a group 
of  action  statements  which  are  to  be  executed  only  if  a 
preceding  condition  was  false.  This  statement  is  not 
reguired  and  it  should  only  be  used  when  there  are  both  true 
and  false  actions  (true  actions  consist  of  those  actions 
immediately  following  the  condition  and  continuing  until  an 
ELSE  or  CONTINUE  statement  is  encountered)  . False  actions 
commence  with  the  first  action  following  the  ELSE  statement 
and  continue  until  a CONTINUE  statement  is  encountered. 

Example  - 


...IF  THE  COUNT  IS  GREATER  THAN  12  COMPUTE  COUNT  = COUNT 
*2  ELSE  HOVE  ZEROS  TO~COUNT  CONTINUE.  . . 

In  the  preceding  example,  if  the  condition  is  true,  the 
COMPUTE  statement  would  be  executed.  If  it  is  false,  the 
HOVE  statement  would  be  executed.  Any  number  of  actions 
could  appear  where  these  two  actions  appear. 


9. 3. 3. 5 The  CONTINUE  Statement 

The  CONTINUE  statement  identifies  the  point,  following 
a condition,  that  execution  of  nonconditional  statements  is 
resumed.  There  are  no  exceptions;  each  IF  statement  must 
have  associated  with  it  a corresponding  CONTINUE  statement. 
All  NFL  statements  which  follow  an  IF  statement  are 
considered  to  be  part  of  the  IF  statement.  To  terminate  an 
IF  block,  a CONTINUE  statement  is  required. 

Example  - 


•••If  FIEID  IS  NOT  EQUAL  TO  BLANKS  HOVE  FIELD  TO  REC 

COmNUE.  • • 

In  the  example  above,  if  the  condition  is  true, 
execution  is  resumed  with  the  next  statement  following  the 
CONTINUE  after  the  true  actions  are  performed.  If  the 
condition  is  false,  execution  is  resumed  with  the  next 
statement  following  the  CONTINUE  statement. 
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Exaaple 


•••IE  FIELD  IS  NOT  EOPAL  TO  BLANKS  MOVE  FIELD  TO  REC 
ELSE  HOVE  REC  TO  FIELD  CONTINOE. . . 

In  the  preceding  exaaple,  if  the  condition  is  true, 
processing  is  the  sane  as  in  the  previous  example.  However, 
if  the  condition  is  false,  the  false  actions  (those  between 
the  ELSE  stateaent  and  the  CONTINOE  statement)  are  executed; 
execution  then  is  resumed  with  the  next  stateaent  following 
the  CONTINUE  stateaent. 


9. 3. 3.6  The  Language  Identifier  Statement 

The  language  identifier  statement  consists  of  the 
characters  NFL.  It  must  appear  as  the  first  statement 
following  the  transaction  descriptor  dec*  (or  the  library 
action  control  card  if  there  is  no  TDD).  It  identifies  the 
language  of  all  statements  between  it  and  the  END  statement 
which  terminates  the  last  NFL  logic  stateaent. 

Exaaple  - 

Library  Action  Control  Card 

Transaction  Descriptor  Deck 

NFL 

Condition  and  Action  Statements 

END. 

In  the  preceding  example,  the  language  is  identified  as 
NFL.  All  statements  between  it  (NFL)  and  the  logic 
statement  END  card  must  be  written  as  NFL  statements. 

POOL  statements  may  be  compiled  in  the  same  execution  as 
NFL  statements.  Grouping  of  NFL  statements  is  recommended. 
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9.4  NFL  Logic  Statement  Examples 

The  following  examples  illustrate  the  setup  of  the  PH 
run  deck  for  updating  the  Logic  Statement  Library,  and  the 
use  of  some  of  the  NFL  language  statements.  All  of  the 
examples  pertain  to  the  TEST360  file. 

All  of  the  sample  logic  statements,  with  the  exception 
of  the  range  statement,  perform  updates  with  transactions 
from  the  report  'RPT360'.  The  different  transaction  formats 
within  this  report  are  identified  by  the  letters  'A'  through 
'G*  in  column  1 of  the  transaction. 

Comments  in  the  form  of  NOTE  statements  are  shown  in 
each  of  the  logic  statements.  The  logic  statements 
illustrated  in  sections  9.4.3  to  9.4.5  and  sections  9.4.7  to 
9.4.8  are  the  NFL  equivalents  of  the  POOL  statements  in 
sections  7.5.3  to  7.5.5  and  section  7.5.7  to  7,5.8, 
respectively.  The  logic  statement  in  section  9.4.6  is  the 
equivalent  of  the  logic  statements  in  sections  8.1  and  8.2. 


9.4.1  FHS  Control  Card 

The  following  FHS  control  card  would  be  used  to  execute 
the  'LIB'  mode  of  FN  to  perform  updates  for  the  Logic 
Statement  Library  for  the  TEST360  file: 

$FM S/LIB,  TEST 3 60 


9.4.2  Library  Action  Card  to  Add  a Report 

The  following  card  would  be  used  to  add  the  report 
'RPT360'  to  the  Logic  Statement  Library.  The  transaction  ID 
field,  for  transactions  within  this  report,  is  located  in 
column  1. 

$AF , RPT360, 1 

This  card  could  also  have  been  punched  as  follows: 

SAB , PPT  360, 1-1 
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However,  since  the  transaction  ID  field  is  only  one  byte 
long,  the  '-I*  is  not  required. 


9.4.3  Logic  Statement  Setup 

The  following  example  illustrates  the  organization  of 
the  library  action  card,  the  TDD  cards,  the  language 
identifier  card,  and  the  NFL  statement  cards  for  an 
Exception  logic  stateaent.  The  saaple  stateaent  perforas 
updates  with  the  'A'  transaction  foraat  of  the  report 
•HPT360*  . 

The  first  card  for  the  stateaent  is  the  library  action 
card.  This  card  specifies  that  the  stateaent  is  to  be 
peraanently  added  to  the  library.  It  also  specifies  that 
the  stateaent  will  perfora  updates  with  the  'A'  transaction 
of  report  'RPT360',  and  that  the  fixed  data  in  that 
transaction  foraat  is  8(7  bytes  long.  The  transaction  does 
not  contain  any  variable  data. 

The  TDD  cards  follow  the  library  action  card.  The  first 
field  in  each  of  these  cards  is  used  to  assign  aneaonics  to 
the  transaction  data  fields. 

The  second  and  third  fields  specify  the  high-order 
position  and  the  low-order  position  of  the  transaction 
fields. 

The  fourth  field  is  used  to  specify  that  a transaction 
field  is  a major  or  user  control  field.  In  the  example, 
SRECID  is  a major  transaction  control  field,  and  it 
corresponds  to  the  data  record  control  group,  'TJIC'.  JSORT 
is  a user  transaction  control  field.  It  is  not  used  in 
matching  a transaction  record  to  a data  record,  but  is 
associated  with  the  record  control  field  to  control  the  file 
processing  sequence. 

The  fifth  field  in  the  TDD  card  indicates  the  type  of 
data  that  the  transaction  fields  will  contain.  The  'A' 
transaction  contains  alphabetic  (A)  data  and  zoned  decimal 
(D)  data  only.  Insertion  of  this  field  is  optional,  with 
the  default  option  being  'D'. 
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The  card  following  the  last  TDD  card  is  the  language 
identifier  card,  and  contains  the  word  *NPL'.  The  word 
'NFL*  «ay  appear  anywhere  between  colain  1 and  coluan  71, 
but  aust  be  in  three  consecutive  card  coluans. 

The  logic  statement's  function  is  described  in  the  NOTE 
statements  which  follow  the  language  identifier  card. 

The  logic  statement  first  tests  the  new  record  switch  by 
using  the  condition/action  statement  sequence  labeled  TEST. 
A new  record  will  be  generated  by  PH  when  no  data  record  can 
be  found  with  a UIC  group  that  Batches  the  contents  of  the 
SR  EC ID  transaction  field  in  an  'A'  transaction.  If  this  has 
occurred,  then  the  true  actions  of  the  condition/action 
stateaent  will  be  executed.  The  true  action  prints  a line 
which  indicates  that  a new  record  was  generated  and  control 
is  then  passed  to  the  statements  following  the  keyword 
CONTINUE.  If  a new  record  was  not  generated,  control  will 
also  be  passed  to  the  stateaents  following  the  keyword 
CONTINUE  because  false  actions  were  not  specified  in  this 
particular  condition/action  statement  sequence. 

The  MOVE  stateaents  aove  the  contents  of  the  transaction 
fields  to  data  file  fields.  Transaction  data  that  is  aoved 
to  coordinate  fields  will  be  converted  automatically  to 
internal  coordinate  format.  The  last  MOVE  stateaent  will 
store  the  date/tise  of  the  update  into  the  data  field  LAUD 
by  referencing  the  SYSDATE  systea  constant. 

The  last  two  condition/action  statement  sequences  are 
the  NPL  equivalent  of  the  POOL  conditional  move 
instructions.  Transaction  data  SHONE  will  be  aoved  to  data 
field  HOME  if  it  is  not  blank  and  $PERS  will  be  aoved  to 
PEBS  if  it  is  not  blank. 

The  END  statement  is  executed  next.  This  statement 
causes  an  exit  froa  the  logic  stateaent. 
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SASP,RPT360f,  A,80 
SR ECID,2,7,Cl,A 
SS0RT,8, 8,C2,  A 
SHONE, 10, 10, , A 
$ATTACH,12,12,,A 
SFUTURE,13, 13,, A 
SPOINT, 1 5,25,  ,0 
SAREAl , 27,37,  , A 
SAREA2, 38, 48,, A 
SAREA3,49,59,  , A 
SPERS.73,80,  ,D 

NFL  ’ 

NOTE  'THIS  LOGIC  STATEMENT  HILL  UPDATE  THE  LOCATION' 
NOTE  'AND  DEPLOYMENT  AREA  OF  THE  SPECIFIED  UNIT.  • 
NOTE  'IF  A NEH  RECORD  IS  GENERATED,  A MESSAGE  HILL  • 
NOTE  'BE  PRINTED  AND  THE  TRANSACTION  FIELDS  HILL  BE' 
NOTE  'MOVED  TO  THE  DATA  FIELDS' 

TEST:  IF  A NEH  RECORD 

PRINT  'NEH  RECORD  GENERATED.  ID  IS  - ',SRECID 
CONTINUE 

HOVE  SATTACH  TO  ATACH  MOVE  $ FUTURE  TO  FUTU 
HOVE  SPOINT  TO  POINT  MOVE  SAREAl  TO  DAPT1 
MOVE  SAREA2  TO  DAPT2  MOVE  S AREA 3 TO  DAPT3 
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HOVE  $AREA4  TO  DAPT4  HOVE  SYSDATE  TO  LAUD 
IF  JHOME  IS  NOT  EQUAL  TO  BLANKS 
HOVE  SHOHE  TO  HOHE  CONTINUE 
IP  SPEFS  IS  NOT  EQUAL  TO  BLANKS 
HOVE  SPERS  TO  PERS  CONTINUE 

END 

J 
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9.4.4  Use  of  Data  Conversion 

The  following  logic  statement  is  used  with  'B* 
transactions.  These  transactions  contain  only  a major 
control  field  in  positions  2 through  7. 

This  logic  statement  verifies  that  the  CNTRY  and  ACTIV 
fields,  in  selected  records,  contain  valid  data. 

It  a new  record  is  generated  by  a ' B*  transaction,  the 
record  will  be  deleted  and  an  exit  from  the  logic  statement 
will  be  taken  when  the  FETUPN  statement  is  executed. 

If  a new  record  is  not  generated,  control  is  passed  to 
the  statements  following  the  keyword  CONTINUF.  Three  work 
areas  are  then  defined  to  held  the  results  of  the  conversion 
routines  or  the  asterisks  error  flag.  Data  field  CNTRY  will 
be  moved  to  the  work  area  CNTBUC  if  the  conversion  by  table 
CTRYS  is  successful.  If  the  conversion  is  unsuccessful,  an 
exit  to  the  statement  labeled  EFR1  will  occur  and  asterisks 
will  be  moved  to  the  work  area  CNTBUC.  The  statement 
labeled  ACT  performs  a similar  function  with  the  data  field 
ACTIV.  Before  the  logic  statement  exits,  the  results  of  the 
two  conversions  will  be  printed.  The  system  word  BLANK  in 
the  PHINT  statement  will  insert  a single  blank  character  in 
the  printed  line. 


177 


- ^ 


* 


FILE  MAINTENANCE  (PH) 


$ASP,RPT360, B, 80 
JR ECID,2,7,C1,A 
NFL 

NOTE  • THIS  LOGIC  STATEMENT  HILL  EXTRACT  THE  COUNTRY  • 

NOTE  ' CODE  AND  THE  ACTIVITY  CODE  FOR  SPECIFIED  UNITS' 

IF  A NEH  RECORD  DELETE  THE  RECORD  RETUPN  CONTINUE 
DEFINE  CNTBUC  AS  #15  DEFINE  ACTBUC  AS  #15 
DEFINE  ASTRK  AS  ***************** 

HOVE  CNTRY  TO  CNTBUC  USING  TABLE  CTRYS  ,EXIT  TO  ERR1 
GO  TO  ACT 

ERR1:  MOVE  ASTRK  TO  CNTBUC 

ACT:  MOVE  ACTIV  TO  ACTBUC  USING  TABLE  ACTVS,  EXIT  TC  ERR2 

GO  TO  PRT 

ERR2:  MOVE  ASTRK  TO  ACTBUC 

PRT:  PRINT  U I C,  BLANK,  CNTBUC, BLANK, ACTBUC 
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9.4.5  Periodic  Set  Processing 

The  following  examples  illustrate  two  methods  for 
updating  periodic  subsets.  The  first  example  uses  an 
Exception  update  statement  to  perform  the  updating  of  the 
record.  The  library  action  card  will  add  statement  *D'  of 
report  type  'RPT360'  permanently  to  the  logic  statement 
library.  The  TDD  cards  assign  mnemonics  to  the  transaction 
fields,  with  transaction  field  SRECID  containing  the  major 
control  field  of  the  record  to  be  processed. 


In  the  first  example,  the  POSITION  AFTER  LAST  statement 
will  ensure  that  the  data  file  is  at  the  beginning  of  the 
subsets.  The  statement  labeled  POS  will  cause  the  subset  of 
periodic  set  one  to  be  searched  for  the  data  field  HECLQ 
being  equal  to  the  contents  of  the  transaction  field  SHBQPT. 
If  found,  the  following  IF  statement  will  modify  data  field 
MEPSD  and  exit  from  the  logic  statement  because  RETURN 
statements  are  in  both  the  true  and  false  actions  part  of 
the  condition/action  statement  sequence.  If  the  subset  is 
not  found,  then  an  exit  will  be  taken  to  the  statement 
labeled  NEW,  where  a new  subset  will  be  created,  transaction 
data  will  be  set  into  the  specified  fields  and  a message 
will  be  printed  to  indicate  this  action. 

In  the  second  example,  the  library  action  card  is  the 
same.  The  TDD  card  for  the  transaction  field  • $H EQPT • is 
different  tor  the  direct  subset  update.  The  control 
parameter  on  the  TDD  card  indicates  that  the  field  is  to  be 
used  as  a subset  control  field.  It  also  carries  a 
corresponding  data  record  subset  control  field  parameter. 
The  data  field  name  •HECLQ*  is  defined  as  a subset  control 
group  in  the  FFT.  If  no  subset  exists  with  a total  record 
control  group  (major  control  field,  set  number,  and  subset 
control  group)  equal  to  the  update  record  control  group 
(SRECID,  set  number,  SHBQPT)  a new  subset  is  generated  by  PH 
and  the  total  record  control  group  is  set  in  the  new  subset 
and  the  new  record  indicator  is  set  on.  If  the  subset 
exists,  the  subset  is  made  active. 


SASP,RPT36?,D,80 
SR ECID, 2, 7, C 1 , A 
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$M EQPT , Ilf, 22,  ,A 
JNOEQPT, 25, 27, ,D 
$ A DDCODE , 29, 29,, A 
NFL 

NOTE  'THIS  LOGIC  STATEMENT  WILL  SEARCH  FOR  THE  SUBSET' 

NOTE  'CONTAINING  THE  EQUIPMENT  TYPE  AND  MILL  ADD  OR  • 

NOTE  'SUBTRACT  THE  NUMBER  OF  ITEMS  AS  SPECIFIED  BY  THE' 

NOTE  'ADD  CODE.  IF  THE  SUBSET  DOES  NOT  EXIST,  A NFM * 

NOTE  'SUBSET  HILL  BE  BUILT  AND  THE  FIELDS  UPDATED' 

POSITION  APTER  LAST  SUBSET  IN  HECLQ  J 

NOTE  'ABOVE  STATEMENT  FORCES  SET  INACTIVE' 

POS:  POSITION  TO  JMEQPT  IN  HECLQ,  EXIT  TO  NEi 

IF  $A  DDCODE  EQUALS  'A* 

COMPUTE  HEPSD  = HEPSD  ♦ JNOEQPT  , RETURN 
ELSE 

COMPUTE  MEPSD  = HEPSD  - JNOEQPT, RETURN 
CONTINUE 

NEH:  BUILD  SUBSET  FOR  HECLQ  HOVE  JMEQPT  TO  HECLQ 
MOVE  JNOEQPT  TO  MEPSD 

PRINT  'NEH  SUBSET  CREATED'  PRINT  JMEQPT 

END 
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$ASP,RPT36p,D,8|l 
$RECID,2,7,C1,A 
SMEQPT,  1(7,22,  , A, S,  HECLQ 
SNOEQPT, 25, 27, , D 
SADDCODE, 29 , 29 , , A 
NFL 

NOTE  ' THIS  STATEMENT  HILL  PERFORM  THE  SAME  FUNCTION,  » 

NOTE  • USING  THE  DIRECT  SUBSET  UPDATE  CAPABILITY.' 

NOTE  • IF  THE  SUBSET  DOES  NOT  EXIST  A NEW  SUBSET  HILL  ' 

NOTE  • BE  GENERATED  AND  THE  SUBSET  CONTROL  FIELD  • J 

NOTE  • HILL  BE  AUTOMATICALLY  SET  BY  FH.  • 

IF  A NEH  RECORD  MOVE  SNOEQPT  TO  MEPSD 

PRINT  'NEH  SUBSET  CREATED'  PRINT  SMEQPT 
RETURN  CONTINUE 
IF  $ A DDCODE  IS  EQUAL  TO  'A' 

COMPUTE  MEPSD  = SNOEQPT  ♦ MEPSD,  RETUP N 
ELSE 

COMPUTE  MEPSD  = SNOEQPT  - MEPSD, RETURN  CONTINUE 

END 


* 


FILE  MAINTENANCE  (FM) 


' I 

*j  9.4.6  Test  for  Numeric  Data 

The  following  logic  statement  illustrates  a simple 
method  of  determining  if  a transaction  field  contains  zoned 
decimal  data.  The  PICTURE  test  is  used  for  this  function. 
The  PICTURE  mask  will  contain  the  letter  N which  signifies 
a numeric  character  test.  If  all  characters  of  the  field 
are  to  be  tested,  then  the  mask  will  contain  a number  of  Ns 
equal  to  the  length  of  the  field.  This  statement  consists 
of  condition/action  statement  sequences  containing  both  true 
and  false  actions.  If  the  transaction  data  contains  all 
numeric  characters,  then  it  is  moved  to  the  data  field.  If 
not,  an  error  message  is  printed. 

I 
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J 

I 
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$ASP,RPT36?,E,8p 
SB EC ID, 2, 7, Cl, A 
SPERSONL,  15,  , D 
SREADAVG, 20, 22, ,D 
SRITNM, 25, 27,  ,D 
NFL 

NOTE  • THIS  LOGIC  STATEMENT  HILL  UPDATE  NUMERIC  FIELDS  IN* 
NOTE  • THE  FIXED  SET.  THE  INPUT  TRANSACTION  FIELDS  ARE  IN' 
NOTE  • ZONED  DECIMAL  FORM.  CHECKS  HILL  BE  HADE  TO  DETERMINE' 
NOTE  • IF  THE  FIELDS  CONTAIN  NUMERIC  CHARACTERS.  IF  AN  ERROR' 
NOTE  ' IS  DETECTED,  AN  ERROR  MESSAGE  AND  THE  FIELD  IN' 

NOTE  * ERROR  HILL  BE  PRINTED* 

IF  SPERSONL  PICTURE  IS  • NNNNNN ' MOVE  SPERSONL  TO  PERS  ELSE 
PRINT  'THE  PERS ONL  FIELD  CONTAINS  NON-NUMERIC  CHARACTERS' 
SPERSONL  CONTINUE  IF  SREADAVG  PICTURE  IS  ' NNN'  HOVE 
SREADAVG  TO  READAVG  ELSE 

PRINT  'THE  READAVG  FIELD  CONTAINS  NON-NUMERIC  CHARACTERS' 
SREADAVG  CONTINUE  IF  SRITNH  PICTURE  IS  'NNN'  MOVE  SRITNM 
TO  RITNM  ELSE  PRINT 

•THE  RITNM  FIELD  CONTAINS  NON-NUMERIC  CHARACTERS'  SRITNM 
CONTINUE  END 
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9.4.7  Production  of  Sunnary  Information 

The  following  logic  statenent  is  a Range  statenent  that 
functions  without  transaction  data.  The  library  action  code 
for  this  statenent  contains  only  the  function  code  »IAST», 
and  there  are  no  TDD  cards  for  this  statenent.  This  type  of 
statenent  nust  be  conpiled  on-line  each  tine  it  is  used. 

This  statenent  uses  the  job  couplete  test  to  deternine 
if  the  processing  is  conplete.  if  processing  is  not 
conplete,  three  COMPOTE  statenents  update  the  desired 
statistics.  when  processing  is  conplete,  these  statistics 
will  be  printed. 
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j 

SAST 

NFL 

NOTE  • RANGE  STATEMENT  TO  CALCULATE  THE  TOTAL  NUMBER  OF* 
NOTE  * UNITS  IN  THE  DATA  FILE,  TOTAL  PERSONNEL  STRENGTH' 
NOTE  • AVERAGE  OF  TOTAL  READINESS  AVERAGE  OF  ALL  UNITS* 

NOTE  • THIS  INFORMATION  HILL  BE  PRINTED  ON  THE* 

NOTE  • AUXILIARY  OUTPUT  FILE* 

DEFINE  COUNT  AS  B1 , DEFINE  TOTPER  AS  B2, DEFINE  AVG  AS  B3 
IF  THE  JOB  IS  NOT  COMPLETE  COMPUTE  COUNT  * COUNT  ♦ 1 
COMPUTE  TOTPER  * TOTPER  ♦ PERS, COMPUTE  AVG  * AVG  ♦ 
READAVG  RETURN  CONTINUE 

PRINT  BLANKS  PRINT  BLANKS  NOTE  'SPACE  THO  LINES* 

PRINT  'TOTAL  NUMBER  OF  UNITS- ', COUNT  PRINT  BLANKS 
PRINT  'TOTAL  PERSONNEL  STRENGTH  OF  ALL  UNITS-'  TOTPER 
PRINT  BLANKS  DEFINE  TOTAVG  AS  112 
COMPUTE  TOTAVG  * AVG  / COUNT 

PRINT  'AVERAGE  OF  TOTAL  READINESS  AVERAGE-'  , TOTAVG 
PRINT  BLANKS  END 

I 

I 

I 
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i 9.4.8  Variable  Field  and  Variable  Set  Processing 

The  following  logic  statements  illustrate  the  use  of  the 
MOVE  statement  when  the  variable  field  or  variable  set  are 
referenced. 

The  first  statement  aoves  information  from  a variable 
transaction  field,  JVAR,  to  the  variable  field  COMMENT. 
Existing  information  in  COMMENT  will  be  destroyed.  When  the 
data  transfer  takes  place,  the  data  is  truncated  so  that  any 
trailing  blanks  in  the  variable  transaction  field  are  not 
moved. 

The  second  statement  appends  information  to  the  variable 
set  REFER.  Since  the  information  to  be  transferred  is  in  a 
! fixed  length  transaction  field,  no  truncation  takes  place. 


J 
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SASP,RPT360,F,10,11 
SR EC ID, 2, 7, Cl, A 
SA VR , 1 1 

NFL 

NOTE  * THIS  LOGIC  STATEMENT  REPLACES  THE  INFORMATION* 

NOTE  • IN  THE  VARIABLE  FIELD  COMMENT  WITH  THE  • 

NOTE  • INFORMATION  IN  THE  VARIABLE  LENGTH  TRANSACTION' 

NOTE  • FIELD  $VAR.  ' 

MOVE  SVAR  TO  COMMENT 

END  ) 

SA:>P,RPT36?,G,80 
SRECID , 2, 7,C 1 , A 
SVAR, 31,89*, A 
NFL 

NOTE  • THIS  LOGIC  STATEMENT  APPENDS  THE  INFORMATION  IN' 

NOTE  • THE  TRANSACTION  FIELD  SVAR  TO  THE  INFORMATION* 

NOTE  ' IN  THE  VARIABLE  SET  REFER.' 

ATTACH  SVAR  TO  REFSh 
END 
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9.5  Suaaary  of  NFL  Condition  and  Action  Statement 

Syntax 

The  following  shows  the  syntax  fonat  for  NFL 
conditional  and  action  stateaents. 


The  following  legends  are  used: 


TF 

DF 

IA 

HA 

LV 


-Transaction  Field  Naae 
-Data  File  Naae 
-Indirect  Address  Naae 
-work  Area  Naae 
-Literal  Value 


PF 

SN 

FC 

ST 

SL 

PH 

BM 

£ } 

Note:  Partial  field  notation 
only  for  SYSDATE. 


-Partial  Field  Value 

-Set  Nuaber 

-Figuration  Constant  (STSDATE, 
ZERO,  ZEROS,  ZEROES,  BLANK, 
BLANKS) 

-Subroutine  or  Table  Naae 

-Syabolic  Stateaent  Naae 

-Picture  Mask  designated  as 
an  alpha  LV 

-Bit  Mark  designated  as  an  un- 
signed nuaeric  LV  consisting 
of  ones  and  zeros 

-Optional  Words 

-Choose  One  Word 
figurative  constants  is  valid 
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IF  Statement  (Non-betveen  Relational) 


EQ 

TF[  PF  ] 

TF[  PF  ] 

NE 

DF[  PF  ] 

DF[PF] 

EQUAL  [TO] 

NA£PF] 

NA[  PF] 

EQUALS 

pqpp] 

FC[  PF  ] 

IA 

IA 

LV 

LV 

MULTIPLE  OPERANDS 
PERMITTED 


TF(PP] 

DF[  PF  ] 

IF  NA[  PF  ] [IS]  [NOT] 
IA 


LT  TF[ PF ] 

GT  DF[  PF  ] 

LE  NA[PF] 

GE  [THAN]  PC[ PF ] 
LESS  IA 

GREATER  LV 

SINGLE  OPERAND  ONLY 
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IP  Statement  (Between  Relation) 


TF[P?  ] 

DF[  P P ] 

IP  IA[PF]  [IS]  [NOT] 

IA 


TP[ PP  ] 

TF[  PP] 

BT 

DP[ PP  ] 

DP[  PP  ] 

WA[ PP  ] / 

WA[  PP] 

BETWEEN 

PC(  PP  ] 

FC[ PP  ] 

IA 

IA 

LV 

LV 

MULTIPLE 

OPERANDS 

PERMITTED 

BETWEEN  OPERAND  FORMAT: 

NO  PARTIAL  FIELD  - NEQPT/S ERV  or  HEQPT  / SERV 

WITH  PARTIAL  FIELD  - HEQPT  1/2  / SER  3/4 

HEQPT  / SERV  3/4 
HEQPT  1/2  / SERV 


IF  Statement  (Table  Relation) 

TF[  PP  ] TAB 

IP  DF[  PP ] [IS]  [NOT]  [IN]  ST 

WA[PF]  TABLE 

IA 


» 


» 


IP  Stateaent  (Picture  Relation) 


TF[PF]  PIC 

IP  DF[  PP  ] 

WA[  PP  ] PICTURE 

IA 


[IS]  [NOT]  PH 
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IF  Statement  (Bit  Test) 

TF[  PF] 

DF[  PF] 

IF  HA[  PF  ] BIT  BM  [IS]  [NOT] 
IA 


ON 

OFF 


IF  Statement  (Switch  Test) 

ON 

IF  UA  [IS]  [NOT] 

OFF 


IF  Statement  (Status  Test) 
IF  [NOT]  NEN  RECORD 


IF  [THE]  JOB  [IS]  [NOT] 


IF  OVERFLOW  [ IS  ] [ NOT] 


COMPLETE 

COMPLETED 

ON 

OFF 


1 


j 

■ 

i 


i 


i. 
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ACTION  Statements 
00  [TO]  SL 


ON 

TURN  HA 

OPP 


DP 

TF[PP] 

♦ TP[PF] 

COMPUTE 

HA  * 

DP[  PP] 

DP[PP] 

IA 

H A[  PP  ] 

* HA[  PP  ] 

FC[ PP ] 

/ PC[  PP  ] 

IA 

IA 

LV 

LV 

HRITE 

TP[ PP  ] 

TP[  PP  ] 

PRINT 

[ON  n] 

DP[ PP] 

DF[ PP  ] 

PUNCH 

HA[ PP  ] 

HA[  PP  ] 

. DISPLAY 

PC[  PP  ] 

PC[PP] 

5 

LV 

LV 

n = unit  nuaber 


for  PRINT,  PUNCH,  DISPLAY  n nay  be  1 or  2 
for  HRITE  n may  be  1 through  5 
If  [ON  n]  not  specified,  * unit  1 is  assumed. 


BUILD  SUBSET  IA 


TF[  PP  ] 

DF[ PP ] DP 

ATTACH  HA[  PP  ] [ TO  ] 

FC[ PP  ] 

IA 
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LV 


! 


DELETE  RECOB D 


FIELD 

DP 

DELETE 

SUBSET 

I A 

SET 

SN 

TP£  PF  ] 

SUB 

DP[  PF  j 

r>P[  pf] 

TAB 

MOVE  U A[  PF  ] [TO] 

WA[PF]  [USING] 

SUBROUTINE  ST  EXIT  SL 

PC[  PF] 

TA 

TABLE 

IA 

LV 

DP 

LOCATE  SET  IA  EXIT  SL 

SN 


DP 

STEP  SET  IA  EXIT  SL 

SN 


J 
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POSITION  [TO  ] 


TF[ PP  ] 

DF[  PF  ] 

DF(  P F ] 

HA[PP]  [IN] 

EXIT  SL 

IA 

IA 

LV 

DF 

POSITION  [TO]  FIPST  [SUBSET]  [IN]  IA  EXIT  SL 

SN 


DF 

POSITION  [TO]  NEXT  [SUBSET]  [IN]  IA  EXIT  SL 

SN 


DF 

POSITION  [APTEP]  LAST 

[SUBSET]  [IN] 

IA 

EXIT 

SN 

AS 

DEFINE  HA  LV 

TO 

Hn/m 

AS 

PC 

DEFINE  HA 

•n  VALUE 

[IS) 

TO 

Bn 

LV 

| 


~ : 
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Appendix 


Utilizing  a NIPS  File  as  PH  Transaction  Input 


This  appendix  specifies  the  preparation  requirements  for 
using  a NIPS  360  FFS  data  base  as  a transaction  input  file. 

The  high-order  location,  length  and  mode  of  each  file 
field  may  be  obtained  from  the  File  Format  Record  List 
portion  of  the  FPT  listing.  These  high- order  locations  are 
relative  0 and  must  be  adjusted  to  relative  1 (add  1 to  each 
H.O.  location)  for  FH  TDD  cards.  If  in  doubt,  run  an  FR  and 
list  the  logic  statements  produced.  The  TDD  cards  of  these 
statements  will  also  describe  each  field  in  the  file  being 
revised. 

If  the  file  has  periodic  sets,  a logic  statement  can  be 
written  for  each  set.  The  LS  name  would  be  formed  from  two 
bytes.  The  first  byte  would  be  an  'R'  which  is  in  position 
6 (relative  to  1)  of  every  data  record.  The  second  would  be 
one  hex  byte  which  specifies  the  set  I.D.  The  location  of 
this  byte  can  be  found  under  the  label  'H.O.  SET  ID*  in  the 
Control  Record  Contents  portion  of  the  FFT  list.  Again, 
this  is  relative  to  0;  so  add  one  for  the  TDD  card.  This 
byte  is  a binary  0 for  the  fixed  set,  binary  1 for  the  first 
periodic  set,  binary  2 for  the  second,  etc. 

The  TRANS  DD  statement  in  the  FH  procedure  should  be 
overridden  to  describe  the  NIPS  file.  The  DCB  for  a NIPS 
ISAH  file  must  include  the  parameter  DSORG-IS. 

The  transaction  source  field  on  the  FH  control  card 
should  be  specified  as  SAH  for  a sequential  NIPS  data  base 
or  ISAH  for  an  index  sequential  NIPS  data  base. 

Using  file  TEST360  as  an  example,  the  record  control  is 
six  bytes  long  which  places  the  SET  ID  at  location  13  of 
each  file  record. 
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a.  The  Add  Report  card  would  appear  as  follows: 

$AR,REPT,6,13 

b.  The  Add  Statement  card  for  the  fixed  set 
statement  would  appear  as  follows: 

$ASP,REPT,R*,329 


logic 


where  * is  a binary  ft  (12-JF-8-1  punch)  and  32 0 is 
the  set  length. 


DISTRIBUTION 


CCTC  CODES  COPIES 


Cl  24  (Reference  and  Record) 3 

Cl  2 4 (Record  Copy)  Stock 6 

C2  40  . 20 

C315 1 

C341  (Maintenance  Contractor) 10 

C34 1 (Stock) 70 


EXTERNAL 

Director  of  Administrative  Services,  Office  of 
the  Joint  Chiefs  of  Staff 

Attn:  Chief,  Personnel  Division,  Room  1A724,  The 
Pentayon  Washington,  D.C.  20301 1 

Director  for  Personnel,  J-1  , Office  of  the  Joint 
Chiefs  of  Staff,  Attn:  Chief,  Data  Service  Office, 
Room  1B738C,  The  Pentagon,  Washington , D.C. 

20301 1 

Director  for  Operations,  J-3 , Office  of  the  Joint 
Chiefs  of  Staff,  Attn:  P £ AD,  Room  2B870,  The 
Pentayon,  Washington,  D.C.  20301 1 

Director  for  Operations,  J-3,  Office  of  the  Joint 
Chiefs  of  Staff,  Attn:  Deputy  Director  for 
Operations  (Reconnaisance  and  Electronic  Warfare) 


Room  2D921 , The  Pentagon,  Washington,  D.C. 

20301 1 

Director  for  Logistics,  J-4,  Office  of  the 
Joint  Chiefs  of  Staff,  Room  2E828,  The  Pentagon, 
Washington,  D.C.  20301 1 

Chief,  Studies  Analysis  and  Gaming  Agency,  Attn: 
Chief,  Force  Analysis  Branch,  Room  1D928A,  The 
Pentagon,  Washington,  D.C.  20301 1 

Automatic  Data  Processing,  Liaison  Office 
National  Military  Command  Center,  Room  2D901A, 

The  Pentagon,  Washington,  D.C.  20301 1 


197 


* y . rms— 


EXTERNAL 


COPIES 


: 

I 


I 


. 


i 


¥ 


i 

! 


I 


Automatic  Data  Processing  Division 

Supreme  Headquarters  Allied  Powers,  Europe 

Attn:  SA  t P Branch,  APO  New  York  09055 1 

Director,  Defense  Communications  Agency,  Office 
Of  MEECN  System  Engineering,  Attn:  Code  960T, 
Washington,  D.C.  20301 1 

Director,  Defense  Communications  Engineering 

Center,  Hybrid  Simulation  Facility,  1 8G0 

Wiehl  Avenue,-  Reston,  VA  22070 1 

Director,  Defense  Intelligence  Agency 
Attn:  DS  - 5C2 

Washington,  D.C.  20301 5 

Commander-in-Chief,  Pacific,  Attn:  J6331 , 

FPO  San  Francisco,  96610 1 

Commander-in-Chief,  US  Army  Europe  and 

Seventh  Army  ATTN:  OPS  APO  New  York.  09  403 1 

Commanding  General,  US  Army  Forces  Command, 

Attn:  Data  Support  Division,  Building  206, 

Fort  McPherson,  GA  30303 1 

Commander,  Fleet  Intelligence  Center,  Europe, 

Box  18,  Naval  Air  Station,  Jacksonville, 

Florida  32212 1 

Commanding  Officer,  Naval  Air  Engineering 
Center,  Ground  Support  Equipment  Department, 

SE  314,  Building  76-1,  Philadelphia,  PA  19112  1 

Commanding  Officer,  Naval  Security  Group 
Command,  3801  Nebraska  Avenue,  N.W.  Attn:  GP22, 
Washington,  D.C.  20390 1 


Commanding  Officer,  Navy  Ships  Parts  Control 
Center,  Attn:  Code  712,  Mechanicsburg , PA  17055  1 

Headquarters,  US  Marino  Corps,  Attn:  System 
Design  and  Programming  Section  (MC-JSMD-7) 
Washington,  D.C.  20380 1 
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I 


i 


I 


EXTERNAL 


COPIES 


i 


1 


k 


1 


Commanding  Officer,  US  Army  Forces  Command 

Intoll igence  Center,  Attn:  AFIC-PD,  Fort 

Bragg,  NC  28307 1 

Commander,  US  Army  Foreign  Science  and 
Technology  Center,  Attn:  AMXSJ-CS,  220 
Seventh  Street  NE,  Charlottsville , VA  22212 — 1 

Commanding  Officer,  US  Army  Security  Agency, 
Command  Data  -Systems  Activity  (CDSA)  Arlington 
Hall  Station,  Arlington,  VA  22212 1 

Commanding  Officer,  US  Army  Security  Agency 
Field  Station  - Augsburg,  Attn:  IAEADP , 

APO  New  York  09458 1 

Commander,  Fleet  Intelligence  Center,  Atlantic, 
Attn:  DPS,  Norfolk,  VA  2351  1 1 

Commander,  Fleet  Intelligence  Center,  Pacific, 

Box  500,  Pearl  Harbor,  HI  96860 1 


Air  Force  Operations  Center,  Attn:  Systems 
Division  (XOOCSC)  Washington,  D.C.  20301 1 

Commander,  Armed  Forces  Air  Intelligence 
Training  Center,  TTMNIM  (360  FFS) , Lowry 
AFB , Co  80230 1 

Commander,  Air  Force  Data  Services  Center, 

Attn:  Director  of  System  Support,  Washington, 

D.C.  20330 1 


Commander-in-Chief,  US  Air  Forces  in  Europe, 

Attn:  ACDI  APO  New  York  093  32 1 

Commander,  USAF  Tactical  Air  Command,  Langley 


AFB,  VA  23665 1 

Commander,  Space  and  Missile  Test  Center,  Attn: 

(ROCA)  Building  7000,  Vandenberg,  AFB,  CA 

93437 1 
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EXTERNAL 


COPIES 


Naval  Air  Systems  Command,  Naval  Air  Station, 

Code  13999,  Jacksonville,  Florida  32212 1 

Commanding  General , US  Army  Computer  Systems 
Command,  Attn:  Support  Operations  Directorate, 

Fort  Delvoir,  VA • 1 

Defense  Documentation  Center,  Cameron  Station, 
Alexandria,  VA  22314 12 


TOTAL  1 59 


J 


i 
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